AgentCore Observability, no collector required.

Yesterday we plugged every Lambda, REST API, and external MCP server into the agent via Gateway. Today's question is the one that turns up the morning after that ships: where do the traces go? AgentCore Observability is the OpenTelemetry-native monitoring layer that captures session metrics, structured spans, and application logs for every AgentCore resource — and surfaces them in the CloudWatch generative AI observability page without you wiring up a collector.

01The shape of the system

From the observability overview: "Amazon Bedrock AgentCore provides a number of built-in metrics to monitor the performance of resources for the AgentCore runtime, memory, gateway, built-in tools, and identity resource types." That sentence is doing a lot of work. The shape is:

• Service-provided telemetry is emitted by AgentCore itself for every resource — Runtime, Memory, Gateway, Built-in Tools, Identity, Payments, Policy.
• Code-emitted telemetry is whatever you (or your framework) instrument via the AWS Distro for OpenTelemetry (ADOT) SDK — GenAI semantic-convention spans for LLM calls, tool calls, and agent turns.
• Everything lands in Amazon CloudWatch: spans in the aws/spans log group, structured EMF metrics under the bedrock-agentcore namespace, application logs in per-resource log groups, and a tailored dashboard at the generative AI observability page in the CloudWatch console.

02The one-time setup: Transaction Search

Before any AgentCore span will become searchable, you have to flip CloudWatch Transaction Search on in the account and Region. From Get started with AgentCore Observability: "After you enable Transaction Search, it can take ten minutes for spans to become available for search and analysis." It's three CLI calls:

A few things the console-driven setup hides:

• The default indexing rule keeps 1% of spans at no cost — raise the percentage only when you understand the per-span ingest cost.
• Spans land in the well-known log group aws/spans. The trace-search console reads from there directly.
• Console users get to the same setting under Application Signals (APM) → Transaction search → Enable Transaction Search.

03Runtime-hosted agents: instrumentation is automatic

For agents you deploy via the AgentCore CLI, you write zero OTEL code. The runtime ships ADOT, runs opentelemetry-instrument ahead of your entrypoint, and emits OTEL traces, EMF metrics, and structured logs for you. From the get-started doc:

Two CloudWatch log groups are created for each Runtime agent:

The Runtime span is documented in AgentCore generated runtime observability data. It's a single operation:

• Span name: InvokeAgentRuntime
• Attributes: aws.operation.name, aws.resource.arn, aws.request_id, aws.agent.id, aws.endpoint.name, aws.account.id, session.id, latency_ms, error_type, aws.resource.type, aws.xray.origin, aws.region.
• error_type is one of throttle, system, or user, and is only present on failed invocations.

That gives you a usable trace tree on day one even before you add your own framework spans.

04Non-runtime agents: the OTEL env vars

For agents hosted elsewhere — ECS, EKS, Lambda, anything outside AgentCore Runtime — you get the same dashboards by adding the ADOT distro to your image and exporting six environment variables. From the configure doc:

Six env vars + ADOT distro = same dashboard

Three things that catch people:

• aws-opentelemetry-distro>=0.10.0 is the minimum version pinned in the doc — older releases predate the GenAI conventions AgentCore expects.
• For frameworks other than Strands, LangChain, or CrewAI, you also need a GenAI instrumentation library — OpenInference, Openllmetry, OpenLit, or Traceloop are the four the docs explicitly support.
• Session correlation is opt-in. The recommended snippet:
  ctx = baggage.set_baggage("session.id", session_id); context.attach(ctx). Without this, the dashboard groups spans by trace ID but not by session ID — and the per-session views go empty.

05The six headers that change the trace

Whether you invoke through boto3 or curl, AgentCore Runtime honours six HTTP headers that flow straight into the OTEL pipeline and the resulting spans. From the enhanced runtime observability table:

The practical implication: if you have a frontend already instrumented with W3C traceparent, you can forward it on the invoke_agent_runtime call and the resulting agent spans plug straight into your existing distributed trace.

06Service-provided telemetry by resource type

Each AgentCore resource type ships a different default. From Amazon Bedrock AgentCore generated observability data:

* Memory spans and logs are off by default — you turn them on per memory resource via the Tracing and Log delivery panes.
** Policy observability surfaces under the Gateway tab on the GenAI Observability page.

The Runtime is the only resource whose default telemetry shows up in the GenAI Observability dashboard with no extra configuration. For Memory, Gateway, Identity, and Built-in Tools you have to attach a log destination (CloudWatch Logs, S3, or Firehose) and, where applicable, toggle the Tracing widget — once you do, spans flow into the same aws/spans log group as everything else.

07Limits and gotchas worth knowing

Distilled from the get-started, configure, and runtime-metrics pages:

• 10 minutes after enabling Transaction Search before spans appear. Plan the runbook around it.
• Default span sampling is 1%. Production debugging usually needs 5–10%; pricing matters above that.
• Resource-usage telemetry can lag by up to 60 minutes and precision differs across metrics — don't alert on CPUUsed-vCPUHours for real-time scaling decisions.
• USAGE_LOGS are 1-second granularity and contain agent.runtime.vcpu.hours.used / agent.runtime.memory.gb_hours.used per session. They're vended; you opt them in per agent.
• Memory spans require enablement. A memory resource with the Tracing toggle off will surface zero spans even with Transaction Search on.
• WebSocket agents emit extra metrics — ActiveStreamingConnections, InboundStreamingBytesProcessed, OutboundStreamingBytesProcessed. Sum over 1 minute, not average.
• Custom dashboards live under namespace bedrock-agentcore. ADOT writes EMF metrics there — that's the namespace to point CloudWatch alarms at.

08Try it in five minutes

A complete loop on a Runtime-hosted Strands agent:

Within a minute you should see one session, one trace whose root is InvokeAgentRuntime, child spans for each LLM call (with GenAI semantic-convention attributes like gen_ai.system, gen_ai.request.model, gen_ai.usage.prompt_tokens), and a metrics row under the bedrock-agentcore namespace.

Tomorrow we'll look at AgentCore Code Interpreter — the sandboxed code-execution tool and how its session model differs from Runtime's.