AWS has published a technical walkthrough for sending telemetry from AI agents running outside its cloud into Amazon Bedrock AgentCore Observability. The approach covers on-premises environments, developer machines, Google Cloud Platform and Microsoft Azure, giving teams a way to use AWS dashboards without moving the agent workloads themselves to AWS.

The guidance matters because AgentCore Observability does not natively monitor agents deployed outside the AWS AgentCore runtime. AWS’s documented workaround combines the AWS Distro for OpenTelemetry (ADOT), Amazon CloudWatch and AWS Identity and Access Management (IAM) credentials to collect traces, metrics and logs from external environments.

Extending AgentCore beyond AWS-hosted runtimes

Amazon Bedrock AgentCore is positioned by AWS as a platform for building, connecting and optimizing agents built with different frameworks and models. Its observability capability is designed to expose details such as agent execution, tool calls, model activity and token usage.

According to the AWS Machine Learning Blog, native support is focused on agents running on the AgentCore runtime in the AWS Cloud. Agents deployed on Amazon Elastic Kubernetes Service, Amazon Elastic Container Service or AWS Lambda can use AWS-native integration patterns, while workloads outside AWS require additional setup.

The newly documented configuration does not relocate those workloads. Instead, ADOT runs alongside the agent application and instruments supported frameworks and model calls. The resulting telemetry is exported to an Amazon CloudWatch OpenTelemetry Protocol endpoint, where it can feed AgentCore Observability dashboards.

AWS’s examples reference agents built with Strands Agents, LangGraph and CrewAI. That makes the walkthrough relevant to teams standardizing on different agent frameworks rather than treating observability as a feature tied to one application stack.

How the cross-cloud telemetry pipeline works

The configuration has three main parts. First, ADOT provides auto-instrumentation for the application. AWS says the OpenTelemetry distribution can patch boto3 for Amazon Bedrock calls and instrument the Strands framework so that reasoning-related spans and generative AI semantic-convention data are emitted.

Second, the external environment needs IAM credentials with permission to send telemetry to AWS services. The permissions listed in the walkthrough include access for CloudWatch metrics, log creation and ingestion, and AWS X-Ray trace operations. The setup also requires outbound HTTPS connectivity to AWS endpoints.

Third, environment variables define the OpenTelemetry routing and authentication settings. The telemetry is authenticated with AWS Signature Version 4, or SigV4, before being sent to the CloudWatch endpoint. CloudWatch then provides the ingestion and storage layer, while AgentCore Observability supplies dashboards tailored to agent activity.

AWS also identifies CloudWatch Transaction Search as a prerequisite that must be enabled once per account. The walkthrough uses Amazon Bedrock model access and Claude Haiku in its example, although the central procedure is about exporting telemetry from external agents rather than introducing a new model.

Evidence, claims and remaining limits

The primary evidence for this development is AWS’s own technical blog post and setup instructions. The separate AWS item in the supplied coverage cluster contains no additional article text, customer testimony or independent validation. As a result, claims about the value of the dashboards, the breadth of framework support and the operational benefits should be treated as vendor-reported guidance rather than independently measured results.

AWS describes the telemetry as providing visibility into reasoning chains, tool invocations and model outputs. It says that visibility can help teams identify hallucinations, harmful or off-topic responses, track token consumption and audit behavior. Those are plausible observability use cases, but the post does not provide benchmark results showing detection accuracy, latency overhead, cost savings or the number of deployments using the configuration.

There is also an important boundary to the announcement. The approach creates a cross-platform monitoring path; it does not make AgentCore Observability a fully local or cloud-neutral service. External agents still send their telemetry into AWS services, and teams must manage the associated IAM permissions, network access, CloudWatch configuration and data-handling policies.

That distinction will matter for organizations whose data residency rules, security architecture or procurement strategy limit the transmission of prompts, outputs or trace details to a third-party cloud. The walkthrough offers a technical route, not evidence that every enterprise requirement has been addressed.

What it means for AI builders and enterprise teams

For developers, the main benefit is operational consistency. A team can run an agent on a local machine during development, in a private data center for production, or on another cloud provider while sending execution data to one AWS monitoring surface. That may reduce the need to build separate dashboards for each deployment location.

The data could also support practical debugging. Traces can connect a user session to model calls, tool invocations and downstream steps, making it easier to investigate failures in workflows that are more complex than a single prompt-response exchange. Token usage can provide a basis for cost monitoring, particularly when agents repeatedly call models or tools.

For enterprise buyers, however, centralization introduces trade-offs. IAM access keys and telemetry containing model inputs or outputs must be protected, scoped and governed. Teams will need to decide which fields are safe to export, how long records should be retained, and whether CloudWatch and AgentCore Observability fit their compliance boundaries.

The setup also creates a degree of AWS dependence even when compute remains elsewhere. Builders using GCP, Azure or on-premises infrastructure can preserve deployment flexibility, but the monitoring control plane, authentication model and storage path described by AWS remain tied to AWS services. That may be attractive for AWS-centered organizations and less compelling for companies pursuing a vendor-neutral OpenTelemetry stack.

What to watch next

The most immediate signal will be whether AWS expands native AgentCore Observability support beyond the AgentCore runtime or continues to rely on ADOT-based integration for external workloads. Documentation on additional framework instrumentation and model providers will show how broadly the pattern works beyond the examples in the post.

Teams evaluating the approach should also watch for concrete information on telemetry costs, export latency, sampling controls, retention options and data redaction. Independent implementation reports would help establish whether the configuration is practical at production scale, rather than only reproducible as a guided example.

Finally, the market will be watching whether other cloud providers respond with comparable cross-environment agent monitoring. As AI agents become distributed across private infrastructure and multiple clouds, observability may become a deciding factor in where teams run their workloads.

Creati.ai perspective

AWS is not announcing that external agents now run natively inside AgentCore Observability. It is documenting a bridge that uses ADOT and CloudWatch to extend the service’s visibility to workloads deployed elsewhere. That is a meaningful operational improvement, but its usefulness depends on whether teams accept AWS as the telemetry control plane.

For builders, the strongest takeaway is architectural: agent monitoring needs to follow the workflow across models, tools and deployment environments. AWS’s approach lowers the integration effort for organizations already invested in its services, while the required credentials and data routing make security, portability and cost questions central to any production rollout.