What happened
AWS describes a reference deployment in which an enterprise orchestrator built with LangChain communicates with a SaaS compliance agent built with Strands Agents. The enterprise and provider run in separate AWS accounts, and neither side depends on the other’s framework or SDK. A third agent, the enterprise context agent, provides internal metadata such as policy rules, account classifications, and escalation contacts. A2A is the protocol used for agent-to-agent communication; the article distinguishes it from MCP, which connects an agent to its own tools and data sources.
The deployment uses Amazon ECS with AWS Fargate for the two enterprise agents and Amazon Bedrock AgentCore for the SaaS agent. Amazon Bedrock supplies models: AWS lists Anthropic Claude Sonnet 4.6 for the orchestrator and SaaS agent, and Amazon Nova Lite for context lookups. Each organization has its own Amazon Cognito user pool. During onboarding they exchange public values such as identity-provider URLs, client IDs, scopes, and endpoints; AWS says no secrets are shared. OAuth bearer tokens authenticate calls in both directions.
At startup, the enterprise orchestrator fetches the SaaS agent’s Agent Card and turns its advertised skills into tools. When a request needs a compliance scan, it calls the SaaS agent over A2A. The SaaS agent can call back to the enterprise context agent at the callback address registered during onboarding, after checking its card and obtaining a token. The SaaS agent publishes one curated skill rather than its internal tool names, and the enterprise side does not gain access to its tools, system prompt, or model choice. AWS presents this separation as a way for a provider to change its internals while retaining a compatible A2A interface.
The walkthrough uses three Jupyter notebooks: about three minutes for enterprise identity setup, five minutes for the SaaS agent, and twenty minutes for enterprise deployment and tests. It targets two AWS accounts in the same supported Region—us-east-1, us-east-2, or us-west-2—and requires Python 3.10 or later plus the specified model access. The demo’s compliance findings are synthetic; AWS says production scanning tools could instead connect to services such as AWS Config, Security Hub, or GuardDuty. AWS warns that the deployment incurs charges, including for always-on infrastructure, and directs users to run cleanup steps when finished.
What the archive adds
New Runtime's earlier coverage on October 2, 2026 described AWS’s use of specialized agents to divide enterprise cloud migration work. This is a new implementation detail on the broader AWS agent-orchestration story: a cross-organization A2A boundary rather than a migration workflow.
Trend signal
This supports agent protocols as an interoperability layer: A2A is the stable external interface while each side can use its own framework and internal tools. The example is a vendor-authored reference architecture, not evidence that independent organizations have broadly adopted this pattern in production.
Why now
AWS frames the example around independent software vendors whose customers may use different agent frameworks. It also says A2A is now a Linux Foundation project, and positions this deployment as a next step beyond its earlier single-framework A2A demonstration: cross-framework interoperability, organizational trust boundaries, and OAuth in both directions.
Why it matters
For teams exposing an agent to customers or partners, the useful design choice is not simply which framework to standardize on. It is which capabilities to expose across the organizational boundary, how to authenticate both parties, and how to keep the public contract stable while internals change. An Agent Card with a curated skill can make that boundary more legible than an integration built around another team’s tool names or SDK.
The example also makes the trust model explicit: each side owns its identity provider, the parties exchange public onboarding values rather than secrets, and a callback is restricted to the customer-registered address. That is a useful pattern to evaluate, not a guarantee of security. Builders still need to review token validation, callback registration, permissions, logging, and costs in their own deployment. The synthetic scan data means the notebooks demonstrate integration mechanics, not production compliance accuracy.
What happens next
- More AWS examples will demonstrate A2A across distinct agent frameworks. (6 months, 65%). Watch for: AWS sample repositories or technical posts pairing A2A clients and servers built with additional SDKs.
Limits and uncertainty
AWS presents an implementation pattern, not independent evidence of production adoption or measured reliability. The compliance scan uses synthetic findings, and the post’s production integrations with AWS Config, Security Hub, or GuardDuty are possibilities rather than demonstrated results. AWS does not establish that the architecture is cheaper or safer than custom integrations, nor report latency, throughput, or operational failure rates. Teams should validate the protocol behavior, identity setup, callback controls, and regional model availability in their own environment before relying on it.
Skill to build now
Take one partner-facing capability and define a minimal Agent Card skill for it, separate from the agent’s internal tools. Then map the trust boundary: who registers the callback URL, which identity provider issues each token, and what data can cross in each direction. A small threat-model and interoperability test based on those decisions will reveal whether A2A fits better than a bespoke SDK integration.
Reader takeaway
A2A can serve as an external contract between agents built with different frameworks, including when those agents belong to different organizations. AWS’s example is useful as a deployment recipe, but its synthetic compliance data and unmeasured production characteristics make it a starting point for testing—not proof that the pattern is ready to adopt unchanged.