Agents that work across organizational boundaries need to find one another, exchange tasks, and collaborate without revealing their internals or forcing both sides onto the same framework. AWS has published a reference architecture that addresses this with the Agent-to-Agent (A2A) protocol, which the company notes is now a Linux Foundation project that AWS supports. Without such a protocol, each cross-organization integration demands custom code for every customer and framework; with A2A, independent software vendors (ISVs) can ship agents that interoperate with whatever A2A-compatible frameworks their customers already run.
Although the post is framed around the ISV scenario, AWS says the same pattern fits any organization exposing agents to partners, customers, or internal teams on different frameworks. New capabilities are added by registering Agent Cards with the orchestrator, leaving running agents untouched.
Architecture across two accounts
The deployed example places three agents in two AWS accounts: one for the enterprise and one for the SaaS provider. A2A carries the traffic between them, authenticated with OAuth in both directions, and each account runs its own Amazon Cognito user pool so that every side signs in through its own identity provider.
Onboarding exchanges only public values: identity provider URLs, client IDs, scopes, and endpoint URLs. Each side then trusts tokens issued by the other's user pool, and no secrets cross the boundary. After onboarding, a request flows as follows: the enterprise app obtains an access token from the enterprise Cognito pool and submits a question over HTTPS to a user API on Amazon API Gateway, then polls for the answer. API Gateway relays the request privately, through a VPC link and an internal Network Load Balancer, to the Enterprise Orchestrator, a LangChain agent. When its model judges that the question requires a compliance scan, the orchestrator gets its own token using a client secret held in AWS Secrets Manager and sends an A2A request to the compliance SaaS agent hosted on Amazon Bedrock AgentCore runtime, selecting the skill it read from that agent's Agent Card at startup. The compliance agent verifies the enterprise context agent's Agent Card at the callback URL registered during onboarding, obtains a token from the SaaS provider's own pool, calls back for account metadata, completes the scan, and returns the result through the orchestrator to the app.
The agents
Two enterprise agents run on Amazon Elastic Container Service (Amazon ECS) with AWS Fargate, inside private subnets of an Amazon VPC with no public IP addresses. The Enterprise Orchestrator is the user entry point: LangChain supplies the framework and tool-calling abstractions, and Amazon Bedrock supplies the foundation models. The orchestrator uses Anthropic Claude Sonnet 4.6. At startup it fetches the SaaS agent's Agent Card from its well-known URL and builds a LangChain tool per advertised skill, so the model picks the tool for each question and no hardcoded routing is needed. It sends scan requests over A2A with OAuth bearer tokens and summarizes findings for leadership. Users reach it through an API Gateway endpoint that accepts only tokens from the enterprise pool.
The second agent, the Enterprise Context Agent, also uses LangChain but runs on Amazon Nova Lite. It serves internal metadata such as policy rules, data classification, business criticality, and escalation contacts including on-call rotations. It is built on 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 it through an API Gateway partner API that accepts only the SaaS provider's callback token.
On the provider side, the Compliance SaaS Agent runs on Amazon Bedrock AgentCore in its own account and is built with the Strands Agents SDK. It checks AWS accounts against the enterprise's internal policies, such as no public storage in production and encryption at rest for confidential data. In production its tools would connect to services like AWS Config, AWS Security Hub, or Amazon GuardDuty; the demo substitutes synthetic findings across multiple accounts. Before scanning, it calls back to the context agent for details only the enterprise holds, which makes the two agents peers rather than client and server. The callback goes only to the address registered at onboarding.
The central design choice is routing all cross-boundary communication through A2A. The enterprise cannot see the SaaS agent's tools, system prompt, or model selection, so the ISV can rework its internals without breaking customer integrations as long as the Agent Card and A2A interface stay compatible. The card publishes a single curated skill rather than internal tool names. In the sample card, that skill is "compliance-scan", the card declares protocolVersion "0.3.0", and its securitySchemes section describes an OAuth 2.0 client-credentials flow against the customer's Cognito token endpoint with the scope "a2a-enterprise-compliance-saas/invoke". Cards are served at /.well-known/agent-card.json.
AWS also draws a line between A2A and the Model Context Protocol (MCP): MCP links an agent to its own tools and data in a client-server model, while A2A links agents to each other as peers. A production SaaS agent could use MCP internally and A2A externally, keeping the outside interface constant.
Implementation highlights
The orchestrator deliberately uses plain httpx calls carrying A2A JSON-RPC (method "message/send") with no dependency on the Strands SDK; if the ISV moved to another A2A-compatible framework, the enterprise side would keep working. Its token handling fails closed and retries once with a forced refresh on HTTP 401. On the callback side, the SaaS agent verifies the customer's context card with an anonymous GET that follows no redirects before obtaining its own token; any failure surfaces to the model as the single message "Enterprise context unavailable" while details remain in the provider's logs.
Every A2A task request carries a JWT. Amazon Bedrock AgentCore is configured with the enterprise pool's discovery URL, one allowed client, and one scope, and validates the JWT on each inbound request. API Gateway JWT authorizers restrict the partner API to the SaaS callback token and the user API to the enterprise app's token. Each account keeps its client secret in AWS Secrets Manager, scoped by IAM and resource policy to the one workload that uses it. The only unauthenticated endpoint is the context agent's public Agent Card. AWS flags one frequent misconfiguration: a Cognito client-credentials token carries client_id and scope but no aud claim, so the API Gateway authorizer checks client_id against the audience list, while AgentCore should be configured with allowedClients and no allowedAudience.
Deployment and testing
The system deploys from three Jupyter notebooks that create five AWS CloudFormation stacks, three in the enterprise account and two in the SaaS provider account. Notebook 1 (enterprise, about 3 minutes) creates the enterprise identity and writes onboarding-request.json; notebook 2 (SaaS provider, about 5 minutes) deploys the compliance agent and returns onboarding-response.json; notebook 3 (enterprise, about 20 minutes) deploys the enterprise agents and runs the tests. The onboarding files contain only public values. Prerequisites include two AWS accounts in us-east-1, us-east-2, or us-west-2, access to Anthropic Claude Sonnet 4.6 in both and Amazon Nova Lite in the enterprise account (with the Anthropic first-time use form submitted), Python 3.10 or later with JupyterLab and AWS CLI version 2 or an Amazon SageMaker AI notebook instance (ml.t3.medium suffices), and IAM roles able to create CloudFormation stacks. Docker is not required locally because AWS CodeBuild builds the container images. The notebooks check Bedrock model access before deploying anything and stop at the first error; Clean up sections sit behind stop cells so Run All cannot reach them.
Notebook 3's end-to-end test submits a question through the user API and polls every 5 seconds. It passes only if the reply contains compliance findings and an on-call rotation code known solely to the context agent, and the partner API access log shows a 200 from the SaaS callback client. A follow-up step runs seven trust-boundary checks sending wrong, missing, or forged tokens to each gate; all must be rejected with 401. In the abridged run AWS published, the end-to-end step finished in 52.5 seconds, the boundary checks in 1.4 seconds, and the report covered two production accounts and six findings with escalation contacts per account.
Costs, production notes, and limitations
Running the solution incurs charges: in the enterprise account the main always-on resources are a NAT gateway, two Fargate tasks, the internal Network Load Balancer, and two interface VPC endpoints, while Amazon Bedrock and AgentCore bill per use. For production, AWS suggests one runtime per customer or a front door accepting multiple customer identity providers, key-based client authentication (private_key_jwt or mutual TLS) instead of client secrets, AWS PrivateLink and in-VPC TLS, customer managed AWS KMS keys, VPC Flow Logs and Network Load Balancer access logs, a Secrets Manager rotation function, and an authenticated onboarding portal. Intermittent HTTP 503 responses through API Gateway may mean cross-zone load balancing is off on the internal Network Load Balancer, since each ECS service runs a single task that can start in either Availability Zone.
AWS stresses that the sample should run only in sandbox accounts with no customer or business data, uses synthetic data exclusively, and does not assess or certify compliance with any law, regulation, or standard. Its controls include HTTPS for every cross-account call, a Bedrock guardrail with prompt-attack and harmful-content filters applied to each model call and to text arriving from the other organization, least-privilege IAM roles, ECS containers with read-only root filesystems and all Linux capabilities dropped on a digest-pinned base image, and complete account isolation with no shared secrets, keys, or IAM permissions. Adding a second ISV currently requires giving the orchestrator one OAuth client and scope per ISV, then repeating the onboarding exchange, adding the new Agent Card URL, and restarting the orchestrator.