Build composable, interoperable multi-agent systems with A2A on AWS

AWS published a reference architecture for building composable, interoperable multi-agent systems using the Agent-to-Agent (A2A) protocol, with a LangChain-based enterprise orchestrator in one AWS account communicating with a Strands Agents-based SaaS agent in a separate AWS account. The design uses OAuth 2.0 and OpenID Connect for authentication in both directions, with each side running its own Amazon Cognito user pool and exchanging only public values such as identity provider URLs, client IDs, scopes and endpoint URLs, so no secrets are shared. AWS notes the A2A protocol is now a Linux Foundation project and that the system can be deployed from three Jupyter notebooks and tested end to end.

Artificial Intelligence https://aws.amazon.com/blogs/machine-learning/ Build composable, interoperable multi-agent systems with A2A on AWS Agents in multi-agent systems that span organizational boundaries often need to collaborate in a composable, interoperable way, with agents that other organizations build and run. They need a way to discover each other, communicate, and exchange tasks without exposing internals or requiring the same framework on both sides. The Agent-to-Agent A2A protocol addresses this constraint. Without A2A, building composable multi-agent systems across organizational boundaries requires custom integration code for each customer and framework. Independent software vendors ISVs can instead build composable, interoperable agents that work with the A2A-compatible frameworks their customers already use. While we frame this post around the ISV use case, the pattern also applies to organizations that expose agents across boundaries, whether to partners, customers, or internal teams that use different frameworks. As your system grows, you add skills by registering Agent Cards with the orchestrator, without changing the agents already running. In this post, we walk through a deployed reference architecture on AWS. A LangChain-based enterprise orchestrator communicates with a Strands Agents-based software as a service SaaS agent across organizational boundaries using A2A, with the enterprise and the SaaS provider in separate AWS accounts. Neither side depends on the other’s framework or SDK, and the two sides share no secrets. We cover the architecture and implementation patterns, then deploy the system from three Jupyter notebooks and run an end-to-end test. The A2A protocol is now a Linux Foundation project https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents , and AWS is among the organizations that support it. With A2A, agents can discover each other, negotiate tasks, and collaborate across organizational boundaries through a standardized protocol. The protocol uses existing authentication standards such as OAuth 2.0 and OpenID Connect OIDC for cross-boundary security, and is designed to work across A2A-compatible frameworks. In Open Protocols for Agent Interoperability Part 4: Inter-Agent Communication on A2A https://aws.amazon.com/blogs/opensource/open-protocols-for-agent-interoperability-part-4-inter-agent-communication-on-a2a/ , we introduced A2A concepts and demonstrated two Strands agents communicating using the protocol on AWS. That post established the foundation with Agent Card discovery, structured task execution, and the A2A server pattern. This post builds on that foundation with cross-framework interoperability, cross-organizational trust boundaries, and OAuth in both directions. Solution overview Three agents run in two AWS accounts, one for the enterprise and one for the SaaS provider. The A2A protocol connects them, with OAuth authentication in both directions. Each account has its own Amazon Cognito https://aws.amazon.com/cognito/ user pool, so each side authenticates with its own identity provider. During onboarding, the enterprise and the SaaS provider exchange only public values, such as identity provider URLs, client IDs, scopes, and endpoint URLs. Each side then trusts tokens from the other side’s user pool, and no secrets are shared. After onboarding, each request follows these steps: 1. The enterprise app gets an access token from the enterprise’s Amazon Cognito user pool. 2. The app sends a question over HTTPS to the user API in Amazon API Gateway, then polls for the answer. 3. Amazon API Gateway https://aws.amazon.com/api-gateway/ forwards the request privately, through a VPC link and an internal Network Load Balancer, to the Enterprise Orchestrator, a LangChain agent. 4. When its model decides that the question needs a compliance scan, the orchestrator gets its own token from the enterprise user pool, using a client secret stored in AWS Secrets Manager https://aws.amazon.com/secrets-manager/ . 5. The orchestrator sends an A2A request to the compliance SaaS agent on Amazon Bedrock AgentCore https://aws.amazon.com/bedrock/agentcore/ runtime, using the skill it read from the agent’s Agent Card at startup. 6. The compliance agent checks the enterprise context agent’s Agent Card at the callback URL registered at onboarding, then gets a token from the SaaS provider’s own pool. 7. The compliance agent calls back to the enterprise context agent for account metadata, finishes its scan, and returns the answer to the orchestrator and then to the app. On the enterprise side, two agents run on Amazon Elastic Container Service https://aws.amazon.com/ecs/ Amazon ECS with AWS Fargate https://aws.amazon.com/fargate/ . The Enterprise Orchestrator is the entry point for users. LangChain provides the agent framework and tool-calling abstractions, and Amazon Bedrock https://aws.amazon.com/bedrock/ provides the foundation models FMs that power each agent’s reasoning. The orchestrator uses LangChain and Amazon Bedrock Anthropic Claude Sonnet 4.6 . At startup, the orchestrator fetches the SaaS agent’s Agent Card from its well-known URL and creates a LangChain tool for each skill described on the card. The model then decides which tool to call based on the user’s question, so the orchestrator needs no hardcoded routing logic. It sends compliance scan requests over A2A with OAuth bearer tokens and summarizes the results for leadership. Users reach the orchestrator through an Amazon API Gateway HTTPS endpoint that accepts only tokens from the enterprise’s own pool. The second enterprise agent provides internal context. The Enterprise Context Agent is built with LangChain and Amazon Bedrock Amazon Nova Lite . It provides internal account metadata such as internal policy rules, data classification, business criticality, and escalation contacts team on-call rotations . The deployed agent uses the official a2a-sdk AgentCard, AgentExecutor, and spec-conformant JSON-RPC routes , pinned to a2a-sdk http-server ==1.2.2. The SaaS agent reaches the context agent through an API Gateway partner API that accepts only the SaaS provider’s callback token. Both enterprise agents run in private subnets of an Amazon Virtual Private Cloud https://aws.amazon.com/vpc/ Amazon VPC , with no public IP addresses. On the SaaS provider side, the Compliance SaaS Agent runs on Amazon Bedrock AgentCore in the SaaS provider’s own AWS account. Built with the Strands Agents SDK https://strandsagents.com/ , it checks AWS accounts against the enterprise’s own internal policies, such as no public storage in production and encryption at rest for confidential data. In production, the scanning tools would connect to services such as AWS Config https://aws.amazon.com/config/ , AWS Security Hub https://aws.amazon.com/security-hub/ , or Amazon GuardDuty https://aws.amazon.com/guardduty/ . For this demo, the agent uses synthetic data that simulates compliance findings across multiple accounts. Before it scans, the SaaS agent calls back to the Enterprise Context Agent for enterprise context, such as which accounts are production, which internal policies apply, and who to escalate to. This bidirectional pattern makes the agents true peers instead of a client and a server. The callback goes only to the address the customer registered at onboarding. The key design decision is to use A2A for all cross-boundary communication. The enterprise has no access to the SaaS agent’s internal tools, system prompt, or model choice. This separation means the ISV can change its internal architecture without changing customer integrations, as long as its Agent Card and A2A interface stay compatible. The SaaS card publishes one curated skill, not its internal tool names. Amazon Bedrock provides API access to multiple foundation models, so each agent can use the model that fits its workload. In this solution, the orchestrator and SaaS agent use Anthropic Claude Sonnet 4.6 for complex reasoning, while the context agent uses Amazon Nova Lite for metadata lookups. You can choose different models based on your own requirements. A2A and the Model Context Protocol MCP solve different problems in this architecture. MCP connects an agent to its own tools and data sources in a client-server model. A2A connects agents to other agents as peers, where neither side exposes its internals. In production, the SaaS agent could use MCP internally to connect to its compliance scanning tools while exposing itself externally through A2A. The external interface stays the same regardless of how the agent connects to its internal tools. Prerequisites The notebooks contain the complete deployment procedure. Before you run them, you need the following: - Two AWS accounts, one for the enterprise and one for the SaaS provider, in the same AWS Region: us-east-1, us-east-2, or us-west-2. In both accounts, access to Anthropic Claude Sonnet 4.6 in Amazon Bedrock, and in the enterprise account, access to Amazon Nova Lite. Before the first run, submit the Anthropic first-time use form in each account, and give the identity you run the notebooks with the AWS Marketplace permissions listed in the Amazon Bedrock model access documentation https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html . Model availability varies by Region. Check the Amazon Bedrock model availability documentation https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html for the current list. - A Jupyter environment with Python 3.10 or later, either: - On your computer: JupyterLab, the AWS Command Line Interface AWS CLI version 2 https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html , and an AWS IAM Identity Center https://aws.amazon.com/iam/identity-center/ profile for each account, set up with aws configure sso https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html . You don’t need Docker: AWS CodeBuild https://aws.amazon.com/codebuild/ builds the container images. - Or an Amazon SageMaker AI https://aws.amazon.com/sagemaker/ai/ notebook instance in each account ml.t3.medium is enough . See the Guide to getting set up with Amazon SageMaker AI https://docs.aws.amazon.com/sagemaker/latest/dg/gs.html . - On your computer: JupyterLab, the - In each account, an AWS Identity and Access Management IAM role with permissions to create AWS CloudFormation stacks https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/control-access-with-iam.html and the resources in them. Each notebook lists the exact permissions in its Reference section. See the IAM User Guide https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html . Notebook 3 also runs the end-to-end test described later in this post, so you can verify the deployment. Running this solution incurs charges for the resources it creates. In the enterprise account, the main always-on resources are a NAT gateway, two AWS Fargate tasks, the internal Network Load Balancer, and two interface VPC endpoints. Amazon Bedrock and Amazon Bedrock AgentCore charge for what you use. Prices vary by AWS Region. See the pricing pages for Amazon VPC https://aws.amazon.com/vpc/pricing/ , AWS Fargate https://aws.amazon.com/fargate/pricing/ , Amazon Bedrock https://aws.amazon.com/bedrock/pricing/ , Amazon Bedrock AgentCore https://aws.amazon.com/bedrock/agentcore/pricing/ , and Elastic Load Balancing https://aws.amazon.com/elasticloadbalancing/pricing/ . Run the Clean up sections when you finish. Implement the solution Deploy the system with three notebooks, run in order with Jupyter, one cell at a time. Notebook 1 enterprise account, about 3 minutes creates the enterprise identity and writes an onboarding request. Notebook 2 SaaS provider account, about 5 minutes deploys the compliance agent and writes an onboarding response. Notebook 3 enterprise account, about 20 minutes deploys the enterprise agents and runs the tests. The onboarding files hold only public values. 1. Clone the GitHub repository https://github.com/aws-samples/sample-a2a-cross-org-agents , and set up two AWS profiles for local runs, or one notebook instance per account with the repository cloned to each. 2. Run notebook 1 in the enterprise account. 3. Give onboarding-request.json to the SaaS provider. 4. Run notebook 2 in the SaaS provider account. 5. Give onboarding-response.json back to the enterprise. 6. Run notebook 3 in the enterprise account. 7. After testing, run notebook 3’s Clean up, then notebook 2’s. The following sections explain the key implementation patterns behind the deployment. Together, they demonstrate three capabilities: - Interoperability across frameworks – A LangChain orchestrator calls a Strands agent using A2A, with neither side depending on the other’s SDK. - Composability across organizational boundaries – An ISV’s compliance agent and an enterprise’s context agent compose into a workflow that neither team built alone. - Bidirectional collaboration with OAuth – Agents act as peers, calling each other across trust boundaries with token-based authentication. With A2A, the ISV in this scenario replaces multiple custom integration paths with a single protocol-based interface. Build the SaaS compliance agent Build the ISV’s compliance agent with the Strands Agents SDK and deploy it to Amazon Bedrock AgentCore. For this demo, the scanning tools return synthetic compliance findings. The agent exposes three compliance tools using the Strands @tool decorator listing available accounts, running compliance scans, and retrieving remediation steps , plus a fourth that calls back to the enterprise, covered in the next section. The Agent Card doesn’t list these tools. It publishes one curated skill, so callers’ models see what the product does, not how it’s built. This simplified example shows the scanning tool: Enable the bidirectional callback This is where the solution goes beyond typical agent integrations. Most agent-to-agent demos show one-way request and response, where a client agent calls a server agent an