Artificial intelligence agents are finally starting to feel less like black boxes and more like traceable software systems. That shift is critical right now, as organizations move from experiments to production agents that make real decisions, touch sensitive data, and can generate very real costs when they misbehave. Amazon Bedrock AgentCore is leaning into that reality with a new round of observability features that centralize telemetry per agent and tighten the link between traces, logs, and prompts. When combined with Elastic Observability, AgentCore provides end-to-end monitoring that correlates platform signals with application-level traces, logs, and metrics to make troubleshooting agents more predictable. These changes are not flashy, but they directly address the day-to-day pain of debugging and governing agents at scale, particularly in light of operational risks prevalent in AI systems.
How we got here: the observability gap in AI agents
For most of the past decade, observability practices in cloud computing focused on traditional microservices. Teams collected metrics, logs, and traces for well-defined APIs written in languages like Java or Python, typically using CloudWatch, X Ray, and later OpenTelemetry as the backbone of their telemetry pipelines.
When generative AI agents arrived, they brought a different kind of complexity. An agent can call tools, consult memory, route across gateways, and generate prompts dynamically, all inside a single user session. Failures often show up as odd reasoning patterns or unexpected tool use, not just as an error code. Early agent observability tended to be fragmented: model logs in one place, tool logs in another, traces in a shared group, and prompts almost nowhere at all. Investigations turned into manual reconstruction of what the agent might have been thinking.
Amazon Bedrock AgentCore Observability emerged to close that gap by treating agents as first-class observable primitives, with curated views for agents, sessions, and traces, plus dashboards and metrics tailored for reasoning workflows. It already provided three core layers of visibility metrics for trend detection, traces for execution detail, and structured logs for context, making it possible to follow each reasoning step and tool invocation across a session. The latest enhancements push that idea further by unifying telemetry around each individual agent.
The core change: unified per agent log groups
The most important development is the ability to consolidate all telemetry for a runtime hosted agent into a single CloudWatch log group dedicated to that agent. In this configuration, spans that describe trace data are delivered to a log stream named spans in the agent log group rather than a shared aws spans group that aggregates traces across many agents.
Structured logs and standard output for the agent already live in the same per agent group, so traces now arrive alongside the logs and prompts that explain what the agent was doing at each step. This sounds subtle, but operationally it is a big deal. When traces and logs share a single per agent group, operators can correlate execution flows, reasoning prompts, tool calls, and system messages from one location without hopping between multiple log groups or accounts.
Investigations move from cross group joins and guesswork to focused queries in one place, which tends to shorten debugging time and reduce production incident duration. On top of that, AgentCore Observability does not stop at the agent itself. It emits metrics, spans, and logs for runtime hosted agents, memory components, gateway resources, built-in tools, and identity-related primitives, all routed into CloudWatch in a consistent format.
That consistency means teams can use the same dashboards, alerts, and queries across the whole agent ecosystem rather than maintaining separate observability stacks for each component.
Defaults and gradual migration: unified traces on your schedule
Amazon is introducing unified traces with controlled defaults that respect existing deployments. Starting July twenty 2026, newly created agents in supported Regions use unified observability by default, sending their spans to the per agent log group without any extra configuration. Teams provisioning new agents after that date automatically benefit from the centralized telemetry model as their baseline.
Existing agents that still write spans to the shared aws spans log group are not forced to move immediately. Instead, each runtime hosted agent can opt in by setting an environment variable named UNIFIED_TRACES_DESTINATION_ENABLED to true in its AgentCore runtime configuration. Agents that already deliver spans to their own log groups can revert to the shared destination by setting that variable to false if they have a specific need to keep traces aggregated.
This environment-driven approach enables gradual, agent-by-agent migration. Operators can update a subset of agents, verify that logs, prompts, and spans are landing in the correct per agent log group, and reverse the change quickly if anything looks off. Agents created before unified span destinations became available in a Region maintain the shared span destination as their default until the environment configuration is changed, which preserves continuity for long-running workloads while still allowing precise control over when each agent transitions.
From an operational perspective, that is the right stance. Production teams are understandably cautious about moving telemetry around because it directly affects security, compliance, and incident response. By letting every agent choose its destination independently, AgentCore aligns with change management practices that expect incremental rollouts and fast rollback options.
Security, compliance, and export: per agent isolation becomes real
Centralizing telemetry into a single per agent log group is not only about convenience. It also simplifies downstream export and security design in very concrete ways. When all logs, spans, and prompts associated with an agent live in that agent group, teams can subscribe the group to one destination for analytics, alerting, or archival and be confident they are capturing the entire picture of that agent behavior.
They can stream data to a monitoring account, a centralized data lake, or an external observability platform without juggling multiple sources per agent. Release notes indicate that monitoring accounts can link up to one hundred thousand log groups across source accounts, and each source account can share data with up to five monitoring accounts, which supports large multi-account observability topologies.
Because each agent owns a distinct log group, administrators can scope IAM permissions to specific agents. They decide who can read or modify observability data for one agent without automatically granting access to another. Customer-managed encryption keys can be applied at the log group level, enabling teams to encrypt each agent group separately in line with isolation and regulatory boundaries.
That is especially valuable for organizations that run agents with different data sensitivity levels or different regional compliance constraints. In practice, per agent isolation also helps with governance. Auditors can review access and retention policies on a per agent basis. Data protection teams can focus on the telemetry for high-risk agents that interact with confidential information while applying more relaxed policies for low-risk agents.
The observability layout starts to mirror the real risk segmentation of the business.
Under the hood: CloudWatch Transaction Search and X Ray
Unified trace delivery relies on the integration between CloudWatch Transaction Search and X Ray, and there are important configuration details teams need to get right. CloudWatch Transaction Search must be enabled so that X Ray can ingest OpenTelemetry spans, store them in CloudWatch Logs, and expose them for trace queries and visualizations.
For agents hosted on AgentCore runtime, the execution role requires permission to attach a resource policy to the agent log group. That policy must allow the X Ray service principal to call PutLogEvents on the group so that span records can be written into the spans stream and indexed according to the configured strategy.
The documentation also notes that teams can control the percentage of traces that are indexed, with a recommendation to begin at one percent at no cost and then adjust upward once they understand their usage patterns. Once these prerequisites are in place, observability views in CloudWatch offer dedicated tabs for AgentCore, including Agents View, Sessions View, and Traces View, along with GenAI Observability dashboards that tie together model invocations and agent telemetry.
The effect is that traces and logs from each primitive memory, gateway, tooling, and more surface at the right span in the trace timeline, so engineers no longer need to jump between log groups to reconstruct causality.
What this means for teams building AI agents
From the vantage point of someone who has watched observability tooling mature over many years, these changes look like a necessary evolution rather than a luxury. AI agents combine model behavior, tool orchestration, and long-term memory, and that complexity demands the same level of operational discipline that serious microservices have enjoyed for years.
On the opportunity side, unified per agent observability can reduce the time between detection and understanding. AgentCore Observability has already shown that structured traces and logs can turn hours of guesswork into minutes of targeted investigation by exposing reasoning steps, tool calls, and divergence points in one place. Consolidating spans into the agent log group tightens that loop even further.
The result tends to be fewer prolonged incidents, lower token consumption from runaway loops, and clearer visibility into performance bottlenecks. There is also a trust dimension. Rich observability, including prompt payloads and trace-level reasoning, enables proper auditing of agent behavior, which is increasingly important as organizations look to demonstrate responsible AI practices.
When operators can show complete telemetry for an agent session, they are better equipped to explain why the agent made a particular decision, where controls were applied, and how failures were detected.
On the risk side, centralization always raises questions about blast radius and dependency. If misconfigured, a per agent log group could become a single point of failure for that agent telemetry. Teams must ensure that CloudWatch Transaction Search, X Ray integration, IAM policies, and encryption are all configured consistently, and they need to monitor for ingestion failures or indexing backlogs.
There is also a learning curve for teams that have not previously used Transaction Search or OpenTelemetry spans. Another consideration is vendor lock-in. These features are clearly optimized for CloudWatch and X Ray and for the AgentCore runtime environment.
Organizations that prefer alternative observability stacks will need to either integrate CloudWatch into their pipeline or run hybrid approaches. The environment variable-based control over destinations does help, but does not eliminate the strategic dependency on the AWS observability ecosystem.
Finally, as agents grow more capable and begin to access broader organizational, web, and paid knowledge sources, telemetry volume will continue to rise. The move to per agent groups and tunable trace indexing is a necessary response, yet teams will still need cost management strategies and sensible retention policies to avoid letting observability storage grow without bound.
How it fits a broader trend
Zooming out, the AgentCore changes are part of a larger trend toward treating AI agents as production software rather than experimental sidecars. Recent updates across Bedrock and AgentCore focus on connecting agents to managed knowledge bases, providing trajectory insights across sessions, and building continuous learning loops around agent performance. Observability is the thread that ties those capabilities together.
The introduction of unified per agent log groups, spans streams aligned with agent logs, and rich GenAI Observability dashboards marks a maturation point. It moves observability from being a convenience to being a structural property of the platform. Instead of asking developers to bolt on tracing and logging, AgentCore runtime now assumes that every agent will be monitored, traced, and audited by default, with configuration designed around gradual adoption and precise control.
That is exactly what responsible AI development looks like in practice. Policies and ethics statements are important, but without detailed telemetry and traceability, they remain aspirational. With these enhancements, teams have a better chance of building agents that are both powerful and accountable.
Key takeaways and what to watch next
Three practical conclusions stand out.
First, observability for AI agents is no longer optional. With per agent log groups that unify spans, structured logs, standard output, and prompts, AgentCore provides a template for how serious teams should monitor agent behavior in production.
Second, the combination of CloudWatch Transaction Search, X Ray span delivery, and GenAI Observability views shifts debugging from scattered logs to precise trace timelines, which can materially reduce incident time and improve operator confidence.
Third, the design choices around per agent isolation IAM scoping and encryption suggest that future agent platforms will increasingly treat observability as a compliance asset, not just a debugging tool.
Looking ahead, the most interesting questions are about how organizations will use this richer telemetry. Expect to see more automated evaluators that watch traces for failure patterns, more fine-grained cost controls tied to token usage metrics, and more governance workflows built on top of detailed agent traces. As those practices emerge, unified observability in platforms like Amazon Bedrock AgentCore will be the infrastructure that quietly makes them possible.
Conclusion
Amazon is pushing AI agents closer to real production reality with a deceptively simple change in Amazon Bedrock AgentCore observability. Unifying logs and traces into a single CloudWatch log group for each agent turns what used to be scattered telemetry into a coherent story, which matters a lot now that teams are moving agents from prototypes to business critical workflows. Better observability is quickly becoming a prerequisite for trustworthy AI, not a nice to have.
From fragmented telemetry to per agent observability
For most of the short history of agentic AI, debugging agents has felt more like forensic work than engineering. Early systems spread logs, traces, and metrics across multiple services, making it hard to answer simple questions such as what an agent actually did in response to a user request or which tool call caused a failure.
Amazon Bedrock AgentCore was introduced to give teams a more structured runtime for agents built on Bedrock, with built in collection of metrics, structured logs, and distributed traces that follow the OpenTelemetry OTEL standard and route to Amazon CloudWatch by default. CloudWatch later added a generative AI observability experience, including dashboards and trace visualizations specifically designed for Bedrock and AgentCore workloads.
The latest observability update continues that evolution. Agent telemetry that previously flowed into separate destinations for logs and spans can now be consolidated into a single CloudWatch log group for each agent. That consolidation is not just cosmetic. It changes how teams monitor, secure, and debug agents at scale.
What unified logs and traces actually change
According to the AgentCore observability configuration guidance, teams can configure the runtime so that spans are delivered to the same CloudWatch log group as the agents structured logs and standard output rather than to a shared aws spans log group. In that configuration the spans for an agent are written into a dedicated spans log stream within that per agent log group, alongside the agents runtime logs and other telemetry.
This unified destination supports three concrete improvements.
1. Per agent scoping of access and encryption
The documentation notes that keeping spans, structured logs, and standard output together in one per agent log group allows access control and encryption policies to be scoped to an individual agent rather than to a global shared trace destination. That gives security and platform teams finer grained control over which people and systems can inspect detailed traces that may contain sensitive context or data.
2. Single location for telemetry export
With all telemetry for an agent collected into one CloudWatch log group, downstream exports to external observability platforms or data lakes can be driven from a single source rather than multiple destinations. This simplifies pipelines that feed specialist tools such as Arize AI, which already integrates with Bedrock Agents observability to analyze hierarchical traces of agent activities from user requests all the way down to individual tool calls and API invocations.
3. Easier trace driven debugging
CloudWatch provides a transaction search experience that operates on these spans, letting engineers filter and explore execution traces, visualize the sequence of tool invocations, and inspect latency and error patterns within a single account level interface. When logs and traces for a specific agent live together, those trace visualizations become a natural extension of log analysis rather than a separate workflow.
Importantly, unified traces are configurable rather than hard wired. Teams can opt in or opt out per agent using the UNIFIED_TRACES_DESTINATION_ENABLED environment variable on the agent runtime, switching between the dedicated per agent log group and the older shared aws spans destination as needed. CloudWatch transaction search must be enabled in the account for spans to be delivered into the agents log group, which makes unified tracing dependent on observability features being correctly configured at the platform level.
How this fits into the broader Bedrock observability stack
This change does not exist in isolation. It builds on a broader observability stack that has been steadily expanding over the last year.
AgentCore already emits built in metrics for agents, gateways, and memory resources, along with logs and spans when observability is enabled. Those metrics and traces flow into CloudWatch under a dedicated Bedrock AgentCore namespace, where teams can use generative AI observability dashboards to view session counts, latency distributions, error breakdowns, and trace visualizations from prompt to response.
The runtime automatically captures session metrics, performance data, error tracking, and complete execution traces including all tool invocations for each agent interaction. CloudWatch then surfaces this data across multiple views such as Agents, Sessions, and Traces, making it possible to move from an overview of agent health down to span level detail about a single request and its chain of tool calls.
By unifying logs and spans per agent, Amazon is essentially tightening the integration between AgentCore and CloudWatch into something that behaves more like a purpose built observability solution for AI agents than a collection of generic cloud monitoring features.
Why this matters for engineering teams and businesses
From an engineering perspective, the unified log group model reduces cognitive and operational overhead. Teams no longer need to remember that logs for an agent live in one CloudWatch location while spans live in another, or wire up multiple destinations when exporting telemetry to third party tools. That simplicity matters at scale, where dozens or hundreds of agents may be running across environments with different teams responsible for them.
More importantly, unified telemetry improves traceability of what agents actually do. The combination of structured logs, spans, and metrics allows engineers to reconstruct a complete execution path for a request, including internal decision points, external service calls, tool invocations, and resource usage. When that data is organized per agent, investigations into odd behavior or failures can focus quickly on the specific agent and session rather than on combing through global trace streams.
For businesses, better observability underpins stronger governance and compliance. Per agent log groups make it easier to align access, retention, and encryption policies with the sensitivity of each agents role, for example restricting access to traces from agents that handle regulated financial or health data more tightly than those used for internal productivity tasks. CloudWatch dashboards and Bedrock AgentCore trace data also help organizations measure performance metrics such as latency, invocation counts, and token usage by model, which feed into cost management and service level objectives for AI workloads.
This is directly connected to trust. When product owners and risk teams can see precisely how agents reason, which tools they invoke, and how guardrails are applied at runtime, they are more willing to approve production deployment for critical use cases rather than limiting agents to experimental sandboxes. Observability does not solve all safety questions, but it turns invisible behavior into auditable behavior.
Benefits compared with earlier approaches
Compared with earlier agent monitoring patterns, several practical benefits stand out.
* Faster diagnosis of production issues
Previously, fragmented telemetry often left teams manually correlating log events with trace identifiers and tool calls across systems, which slowed down incident response. With unified logs and traces, CloudWatch trace visualizations and transaction search can directly link a failing session to specific spans and logs in the same place, reducing the time between detection and root cause identification.
* Cleaner onboarding for new teams
The AgentCore runtime already offered a near zero instrumentation setup in many cases, where adding a small amount of SDK configuration enabled automatic capture of session data, tool invocations, and performance metrics. Consolidated telemetry means new teams have fewer configuration decisions to make and can rely on a standard per agent log structure and CloudWatch dashboard layout from day one.
* Stronger alignment with OpenTelemetry based tooling
Since AgentCore uses OTEL conventions for traces and structured logs, grouping those traces with logs in a single CloudWatch destination makes it simpler to route them to observability tools that expect unified OTEL streams. That improves interoperability with open source and commercial platforms that specialize in analyzing large volumes of AI agent telemetry.
Overall, the update moves Bedrock AgentCore closer to what many observability experts consider table stakes for production AI agents unified, queryable telemetry organized around clear boundaries such as per agent log groups and per session traces.
Risks, tradeoffs, and practical limitations
Despite the clear advantages, there are some tradeoffs and limitations that teams should acknowledge.
First, unified logs and traces concentrate sensitive data in one place. That is a feature for access control, but it also raises the stakes for correctly configured CloudWatch resource policies and encryption, including permissions such as logs PutResourcePolicy that must be granted to the agent execution role. Misconfiguration could expose detailed trace data more broadly than intended or prevent spans from being delivered, undermining the benefits.
Second, CloudWatch costs can rise with richer telemetry. Distributed traces, structured logs, and detailed metrics generate significant data volume, especially for agents that handle high request throughput or large context windows. While unified log groups simplify monitoring, organizations still need retention policies, sampling strategies, and export pipelines that balance observability needs against cost.
Third, unified traces depend on CloudWatch transaction search being enabled and properly configured. The documentation is explicit that spans cannot be delivered to the agent log group if transaction search is not active, which can lead to confusing gaps for teams that expect unified telemetry but have incomplete account level setup.
Finally, there is an ecosystem question. Centralizing observability in AWS services is convenient for teams already invested in Bedrock, but it increases platform lock in compared with more vendor neutral setups that might route telemetry first to an independent observability provider or open source stack. The OTEL foundation of AgentCore telemetry mitigates this to some extent, yet organizations should still consider how easily they can move or replicate observability data if they diversify cloud providers in the future.
Broader implications for the future of AI agent monitoring
From a historical perspective, AI observability has followed a similar path to microservices observability a decade ago. The field moved from basic logs toward metrics, tracing, and structured events as systems became more distributed and complex. Bedrock AgentCore and CloudWatch GenAI observability show that the same pattern is now unfolding for agentic AI workloads.
Unifying logs and traces per agent is a step toward treating agents like first class services with clear operational boundaries, service ownership, and accountability. It makes it easier to embed agents into standard site reliability practices, including runbooks, alerting, and post incident analysis that rely on consistent telemetry.
Looking ahead, richer observability will likely intersect more deeply with evaluation and safety tooling. CloudWatch already publishes evaluation results for Bedrock AgentCore agents into dedicated log groups using embedded metric formats, which allows organizations to analyze evaluation metrics alongside runtime traces and sessions. Combining these data sources opens the door to continuous monitoring of not only whether agents are available and fast, but also whether they behave as intended under real world conditions.
As agents take on more autonomy in complex workflows, from customer service triage to supply chain decisions, the ability to reconstruct their reasoning paths and tool interactions will be central to regulatory compliance and internal governance. The unified log and trace destination within Bedrock AgentCore is an incremental change, but it is aligned with that longer arc.
Key takeaways and what to watch next
The unified logs and traces feature in Amazon Bedrock AgentCore matters because it turns scattered telemetry into a coherent, per agent view that is easier to secure, debug, and export. It builds on a growing stack of generative AI observability capabilities in CloudWatch, including session views, trace visualizations, and tailored dashboards for Bedrock workloads.
For engineering teams, this update simplifies operations and enables faster, more confident debugging of production agents through combined logs and spans in a single CloudWatch location. For businesses and governance teams, it helps enforce per agent security and compliance boundaries while providing the transparency needed to trust agents with more critical tasks.
The most important forward looking question is how quickly organizations will leverage this observability foundation for continuous evaluation and safety monitoring rather than just troubleshooting. That shift from reactive debugging to proactive oversight will likely determine whether AI agents move from promising prototypes to dependable infrastructure across industries in the coming years.
