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 , 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. Figure 1: A2A agents across an enterprise account and a SaaS provider account 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: The enterprise app gets an access token from the enterprise’s Amazon Cognito user pool. The app sends a question over HTTPS to the user API in Amazon API Gateway, then polls for the answer. Amazon API Gateway forwards the request privately, through a VPC link and an internal Network Load Balancer, to the Enterprise Orchestrator, a LangChain agent. 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 . 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. 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. 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. Prerequ