How the A2A Protocol Enables Cross-Organizational Collaboration for Agents Across Frameworks: From Agent Card Discovery to Bidirectional Callbacks
An AWS Machine Learning blog post presents a reference architecture for cross-organizational multi-agent systems: a LangChain orchestrator invokes a Strands compliance agent via the A2A protocol, with each side using independent identity providers for authentication. Agents discover capabilities at runtime through Agent Cards and establish peer-to-peer relationships via bidirectional callbacks, enabling composable collaboration without sharing internal implementations or SDKs.
Cross-organizational multi-agent systems face a specific constraint: two institutions build and run their own agents, which need to discover each other and exchange tasks without exposing internal implementations or requiring both sides to use the same framework. Without a standardized protocol, every new customer or framework combination requires an ISV to write custom integration code. The A2A protocol attempts to replace these disparate paths with a single interface.
The reference architecture provided in the AWS Machine Learning blog runs three agents across two independent AWS accounts. The enterprise-side orchestrator is based on LangChain, invoking Anthropic Claude Sonnet 4.6 for reasoning routing; the SaaS-side compliance agent is built on the Strands Agents SDK and deployed on Amazon Bedrock AgentCore. Both use completely different frameworks and SDKs but communicate via A2A’s JSON-RPC over HTTP. The orchestrator does not depend on the Strands SDK, nor does the compliance agent depend on LangChain—this is the practical meaning of protocol-level interoperability: as long as both sides speak A2A and publish compatible Agent Cards, the frameworks can be swapped independently.
Agent Cards are the core discovery layer of this mechanism. They publish a JSON document at the /.well-known/agent-card.json path, describing the agent’s name, capabilities, and skills. The orchestrator fetches this card at startup, creating a LangChain tool for each skill listed on the card, after which the large language model decides which tool to call based on the user’s question. This means that when an ISV adds or modifies capabilities, it only needs to update the Agent Card; the orchestrator automatically acquires the new skills upon its next restart, eliminating the need for the two teams to coordinate code changes.
A key design decision lies in what the card publishes. Although the compliance agent has three internal tools (listing accounts, executing scans, and retrieving remediation steps), the Agent Card publishes only one curated skill: 'Scan your AWS account, returning findings and remediation steps by severity.' The calling model sees what the product does, not how it is built. This abstraction allows the ISV to refactor its internal architecture—swapping models, tools, or implementations—as long as the skills described in the card remain unchanged, leaving customer integrations unaffected.
Bidirectional callbacks are what set this solution apart from typical agent demonstrations. Most inter-agent communication demos show a unidirectional request-response pattern: a client calls a server agent and waits for the result. However, this pattern fails when the called agent needs information that only the caller possesses. In this architecture, the compliance agent requires enterprise context before scanning—such as which accounts are production environments, which internal policies apply, and who to escalate to—information known only to the enterprise side. The compliance agent calls back to the enterprise context agent via A2A, obtaining a token using its own account’s identity provider and sending a message to the callback address registered by the customer during onboarding. This makes the two agents true peers rather than a client and a server.
Regarding authentication, each account has its own Amazon Cognito user pool, with both sides obtaining tokens from their respective pools. The receiving side trusts only tokens issued by the other party’s pool. During onboarding, the parties exchange only public values—identity provider URLs, client IDs, scopes, and endpoint URLs—without sharing any secrets. Each A2A task request carries a JWT, which the receiver validates for issuer, client, and scope. The only endpoint that does not require authentication is the context agent’s Agent Card, as it only publishes descriptive metadata.
End-to-end testing validated the entire chain: the orchestrator discovered the compliance agent, routed the request, the compliance agent called back to the context agent to retrieve account metadata, executed the scan, and returned a rich report containing data from both agents. The test passed if the reply included compliance findings, contained an on-call rotation code known only to the context agent, and the partner API access logs recorded a 200 response for the callback client. Subsequently, seven trust boundary checks confirmed that each token was valid only where trusted, rejecting errors, missing, or forged tokens.
The applicability boundaries of this reference implementation are noteworthy. It uses synthetic data to simulate compliance findings and does not demonstrate latency, throughput, or fault recovery performance in a production environment. The bidirectional callback pattern requires both parties to maintain identity provider configurations and callback registrations, resulting in higher operational complexity than unidirectional calls. The blog itself lists productionization recommendations: splitting runtimes per customer, replacing client secrets with key-based authentication, enabling PrivateLink and KMS encryption, and configuring VPC flow logs. These notes indicate that the current architecture is a pattern validation, not a ready-to-deploy production product.
The practical implication for readers is this: if an organization is building agent systems that require collaboration across teams or companies, A2A’s Agent Card discovery combined with bidirectional OAuth callbacks offers an alternative to custom integrations. It does not require both parties to use the same framework, share secrets, or modify caller code to expand capabilities; instead, capability expansion is achieved by updating the card. However, the prerequisite for this path is that both parties accept protocol constraints and maintain their own identity infrastructure—an operational commitment in itself.