On this page
A2A Protocol Explained: How Agent-to-Agent Communication Works
The A2A protocol standardizes cross-boundary agent-to-agent coordination, eliminating custom integration debt for multi-agent systems. It operates at a separate layer from MCP, with the two protocols combining to enable production-ready multi-agent architectures. Major cloud providers including Azure, AWS, and Google Cloud have adopted A2A natively.
Microsoft integrated it into Azure AI Foundry. AWS added support through Amazon Bedrock AgentCore. Google shipped it natively across Vertex AI. That kind of tri-cloud alignment in under twelve months is rare — it signals that the coordination problem A2A solves has become a genuine bottleneck, not a theoretical one.
Here’s the core issue: your contract compliance agent written in Python and your security validator written in Go can both work perfectly in isolation. Getting them to cooperate as a single pipeline without rewriting either one is where most multi-agent architectures stall. A2A is the protocol that makes that handoff standardized rather than custom.
The Dual Protocol Stack: Why A2A Doesn’t Replace MCP
The most persistent confusion in this space is treating A2A and MCP as competing standards. They’re not. They operate at different layers of the stack, and production systems need both.
MCP handles the vertical axis — how an agent connects to tools, databases, and data sources. A2A handles the horizontal axis — how agents delegate work to other agents across organizational and vendor boundaries. Your customer support agent uses MCP to query a CRM and invoke a refund API. That same agent uses A2A to hand a “calculate tax implications” subtask to a specialized finance agent from a different vendor. One protocol without the other gives you either a power tool or a coordination layer, not a complete system.
This layered approach is what production teams are converging on, and it’s the architectural pattern that avoids the pitfalls of treating these protocols as either/or choices. If you’re already comfortable with MCP for tool access, think of A2A as the peer-to-peer layer that sits alongside it. For a deeper breakdown of how the two protocols compare, see MCP vs A2A: Why the Real Answer Is “Both in the Right Order”.
How Agent Cards Enable Discovery Without Trust Violations
Every A2A-compliant agent publishes an Agent Card — a JSON metadata document at /.well-known/agent-card.json that declares the agent’s name, capabilities, skills, endpoint URL, and authentication requirements. Before delegating a task, a client agent fetches the card to understand what it’s talking to.
The problem with unsigned cards is obvious once you think about it: any server can impersonate any agent by publishing a card with matching capabilities. A signed Agent Card lets a receiving agent verify the card was issued by the domain owner — the same trust model TLS certificates bring to web servers, now applied to agent identity.
This matters because A2A explicitly does not require agents to share memory, tools, or internal context. Each agent communicates through structured task objects while advertising capabilities via Agent Cards. The requesting agent gets the output it needs, while proprietary data and internal logic remain encapsulated. For teams handling sensitive workflows — financial services, healthcare, supply chain — this “black box” handoff is a security feature, not a limitation.
The Task Lifecycle: Stateful Coordination for Long-Running Work
A2A defines a standard task state machine with six states: submitted, working, input-required, completed, failed, and cancelled. Long-running tasks use Server-Sent Events for real-time progress updates, which means the protocol supports both synchronous API-style exchanges and autonomous tasks that may take hours or days.
The input-required state is worth highlighting. When an agent calls an A2A peer, the receiving agent can push back on incomplete requests and ask clarifying questions. This is fundamentally different from a REST API call that simply returns data or fails. The protocol treats agent-to-agent interaction as a collaboration, not a request-response transaction. That dynamic autonomy is what enables genuinely multi-step workflows where agents negotiate scope, refine plans, and adapt to intermediate results.
v1.0 also added a tasks/list method with filtering and pagination, which makes task inventory and state inspection practical for operators managing dozens or hundreds of concurrent agent tasks.
The Honest Adoption Gaps You Should Know About
The headline numbers are genuinely impressive: 150+ supporting organizations, 22,000+ GitHub stars, SDKs in five languages (Python, JavaScript, Java, Go, and .NET), and native integration into all three major enterprise cloud platforms.
But the framework support picture is uneven. LangGraph, the most widely deployed open-source agent orchestration framework, still lacks a first-class A2A implementation. Most public production use cases are from the protocol’s founding vendors rather than independent adopters.
What this tells you: A2A’s current adoption is being driven by enterprise platform vendors who have baked it into commercial products, while the open-source developer community — the one building the majority of production agents — is lagging behind. The protocol has crossed the enterprise procurement bar (vendor-neutral governance, multi-cloud support, CISO-ready security) faster than it’s crossed the developer experience bar.
Where A2A Fits in Your Architecture
A2A operates at Layer 7, above service mesh technologies like Istio and Linkerd. It integrates via existing sidecar models and leverages the TLS connection provided by the mesh, then adds its own signature chain on top. For teams running service mesh infrastructure, A2A doesn’t replace it — it layers above it.
The protocol is transport-agnostic, supporting HTTP+JSON, gRPC, and JSON-RPC 2.0, with a canonical data model expressed in Protocol Buffers. This means you can start with HTTP for simplicity and move to gRPC for performance without changing your agent logic.
Production deployments already span supply chain, financial services, insurance, and IT operations. The Agent Payments Protocol (AP2) extends A2A to commerce with 60+ payment organizations including Mastercard, PayPal, and American Express, which suggests the protocol is becoming a foundation for agent-to-agent transactions, not just task delegation.
The Decision Framework
Adopt A2A when you have agents running on different platforms that need to cooperate on a shared workflow, or when you’re building multi-agent systems that span team or organizational boundaries. The protocol eliminates the custom integration debt that accumulates when every agent-to-agent handoff requires bespoke glue code.
Don’t adopt A2A when you’re building a single-agent system that just needs tool access — that’s MCP’s domain. And don’t assume the open-source ecosystem has caught up to the enterprise platform support yet. If your team is heavily invested in LangGraph, you’ll likely be writing your own integration layer for the near term.
The strategic calculus is straightforward: enterprises building production multi-agent systems that span multiple teams, frameworks, or organizational boundaries must adopt A2A alongside MCP. Attempting to replicate A2A’s cross-boundary coordination with custom glue code will incur unsustainable integration debt as agent ecosystems continue to fragment across vendors and platforms. The protocol has moved fast enough that treating it as infrastructure rather than experiment is the prudent call — just verify your framework of choice has SDK support before committing.