AWS connects three AI agents across two accounts using A2A

You have built an enterprise AI assistant with LangChain, while your security assessment provider uses Strands. Now you need to connect them: hand over a task, verify access, and tell the external service which internal rules apply at the customer's organization. This usually means adding a dedicated integration layer that both teams have to maintain.

AWS has published an example of this setup using Agent-to-Agent, or A2A. Three agents run across two AWS accounts, exchange tasks, and request context from one another. The article's practical value lies in its concrete architecture for interaction between companies: different frameworks, separate identity systems, and a callback to the customer.

How the external agent learns the company's rules

Imagine a manager asking for the organization's work accounts to be checked for violations of internal security requirements. The enterprise agent receives the request and delegates the assessment to the SaaS provider's agent. But the provider does not inherently know which accounts are used for production, which data is considered confidential, or whom to notify about problems.

The external agent therefore contacts a third participant: an internal context agent. This agent supplies information about accounts, applicable policies, and escalation contacts. With that context, the SaaS agent completes the assessment and returns the result to the enterprise orchestrator, which prepares a response for the user.

For example, a production account might prohibit public storage, while confidential data might require encryption at rest. The enterprise defines these rules. The provider retrieves the information it needs through an agreed interface and uses it to carry out its task.

The demo uses synthetic violation data. The authors describe live connections to AWS Config, Security Hub, or GuardDuty as a next step for a production system. The example therefore demonstrates how to organize the interaction, but does not establish the quality of an automated security audit.

What A2A actually standardizes

At startup, the orchestrator loads the external agent's Agent Card, which describes its capabilities. It creates LangChain tools from the published skills, and the model selects the appropriate tool based on the user's question. This architecture does not require a separately defined route for every question.

The SaaS agent's card publishes a single application-level capability for compliance assessment. Its internal tools, system prompt, and choice of model remain on the provider's side. The provider can change the implementation as long as it maintains compatibility with the card and the external A2A interface.

For a product team, this creates a useful division of responsibility: the customer integrates with a service capability, while the provider independently develops its internals. Interface compatibility still needs to be maintained, however. The protocol does not eliminate the need to agree on how a task should behave and what result it should produce.

In this architecture, A2A also has a distinct role from MCP. An agent can use MCP to connect its own tools and data sources. It uses A2A to delegate work to another agent. A single service can use both protocols: MCP internally and A2A to interact with the customer.

Where the ready-made example ends

Each side uses its own Amazon Cognito user pool. During onboarding, the companies exchange public configuration parameters: addresses, client IDs, and access scopes. They do not exchange secrets, although each side does have secrets for obtaining tokens, stored in Secrets Manager.

Callbacks are allowed only to the address registered when the customer is onboarded. Before making a request, the SaaS agent checks the internal agent's card. This is a significant detail: the destination address comes from the integration configuration, rather than arbitrary text in an incoming task.

Deployment is split across three Jupyter notebooks. The authors estimate the stages at approximately 3, 5, and 20 minutes; preparing accounts and permissions takes additional time. The infrastructure incurs charges, and some resources run continuously, including a NAT gateway, Fargate tasks, and a load balancer.

Developers should explore this example if their agents need to work with services run by partners or different internal teams. A starting point is a single scenario: delegate a task to an external agent, allow a limited context request, and test the entire flow with tokens from both sides. AWS has covered this part in enough concrete detail for the material to serve as a foundation for your own prototype.