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

Artificial Intelligence #

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, 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, 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 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 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 .
5. The orchestrator sends an A2A request to the compliance SaaS agent on Amazon 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 (Amazon ECS) with AWS Fargate. The Enterprise Orchestrator is the entry point for users. LangChain provides the agent framework and tool-calling abstractions, and Amazon 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 (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, 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, AWS Security Hub, or Amazon 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 . Model availability varies by Region. Check theAmazon Bedrock model availability documentation 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 , and anAWS IAM Identity Center profile for each account, set up withaws configure sso . You don’t need Docker:AWS CodeBuild builds the container images.
  • Or an Amazon SageMaker AI notebook instance in each account (ml.t3.medium is enough). See theGuide to getting set up with Amazon SageMaker AI .

• On your computer: JupyterLab, the

• In each account, an AWS Identity and Access Management (IAM) role with permissions to create AWS CloudFormation stacks and the resources in them. Each notebook lists the exact permissions in its Reference section. See theIAM User Guide .

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, AWS Fargate, Amazon Bedrock, Amazon Bedrock AgentCore, and Elastic Load Balancing. 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 , 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