AWS and Linux Foundation publish reference architecture for the A2A protocol between organizations
AWS has described a reference architecture for deploying the A2A protocol, now a Linux Foundation project, for cross-organizational agent communication. An orchestrator in LangChain and a SaaS agent in Strands Agents run in separate AWS accounts and authenticate with each other via OAuth 2.0/OIDC without sharing secret keys.
AWS has published a guide and reference architecture for deploying the Agent-to-Agent (A2A) protocol, now managed by the Linux Foundation and supported by AWS. The protocol addresses the situation where agents belonging to different organizations need to collaborate without one side having to reveal internal tools, system instructions, or model choice to the other, and without needing to write separate integration code for each partner or framework.
The described architecture involves three agents across two separate AWS accounts. On the enterprise side, an orchestrator built on LangChain and Amazon Bedrock with the Claude Sonnet 4.6 model runs on Amazon ECS with AWS Fargate, automatically creating tools based on skill cards (Agent Card) loaded from the SaaS agent, along with a second agent that provides internal context (LangChain, Amazon Bedrock with the Amazon Nova Lite model). On the SaaS provider side, running in a different AWS account, is a Compliance SaaS Agent built on the Strands Agents SDK, deployed on Amazon Bedrock AgentCore, which performs compliance checks while requesting context from the enterprise agent in both directions.
Authentication between the two sides runs through OAuth 2.0 and OpenID Connect, with each side having its own Amazon Cognito user pool, and during onboarding the parties exchange only public values (identity provider URL, client ID, scope, endpoints) — no secret keys are shared. The a2a-sdk used is pinned to version 1.2.2. According to AWS, this approach lets ISVs change their internal architecture without requiring changes to client integrations, as long as the Agent Card and A2A interface remain compatible.
The source article is part of a longer series on interoperable protocols for agents and follows an earlier installment on communication between two Strands agents via A2A. The rest of the described deployment (including the steps in Jupyter notebooks) is not available in the accessible part of the article — details can be found in the source article.
Why it matters
The standardized A2A protocol removes the need to write custom integration code for each partner or framework, so companies offering agents as SaaS can serve clients using different agentic frameworks (LangChain, Strands, and others) through a single interface. It also enables secure cross-organizational communication without sharing secret keys, since authentication runs over standard OAuth 2.0/OIDC and the parties exchange only public values.
Two audiences, two different impacts
What this means
For individuals
Developers working with agentic systems get a documented reference architecture and sample implementation showing how to connect an agent to another agent from a different framework without writing custom integration code.
For a business
Companies offering agents as SaaS or integrating partner agents can use the A2A protocol for cross-organizational collaboration without sharing internal tools, system instructions, or secret keys, which reduces integration costs with clients using different frameworks.
DevelopmentCheck the original
Event sources
only one source so far · 1 publisher, 0 independent. We count feeds from the same owner only once.