Definition
The Agent2Agent Protocol (A2A) is an open standard for how independent AI agents discover one another and hand off work — even when they are built by different teams, run on different infrastructure, and use different frameworks. Where a single agent connects to passive tools through the Model Context Protocol (MCP), A2A governs the harder case: two autonomous agents, neither of which controls the other, agreeing on a task and exchanging results.
The distinction that makes A2A worth learning is autonomy on both sides. When an agent calls a tool, the tool does as it is told. When an agent delegates to another agent over A2A, the receiver decides how to do the job, may ask for more information, and may take minutes or hours to finish. A2A is the protocol for that negotiation, not for a function call dressed up as one.
How It Works
A2A rests on three moving parts.
The first is the Agent Card — a JSON document an agent publishes, typically at a well-known URL on its domain, describing who it is, what it can do, and where to reach it. This is the unit of discovery: before delegating, a client agent reads a candidate's card to confirm the capability actually exists. In version 1.0, released in early 2026, Agent Cards became cryptographically signed, so a receiver can verify the card was issued by the domain owner rather than spoofed — the trust primitive you need before letting an agent you do not control act on your behalf.
The second is discovery: a client agent locates a capable peer, often by consulting a registry of Agent Cards, and selects one whose advertised capabilities match the task.
The third is task delegation. The client sends the task; the remote agent executes it and returns the result, which flows back so the originating agent can continue its own work. A2A runs over ordinary HTTP, using JSON-RPC for structured calls and Server-Sent Events to stream progress on long-running tasks — a design choice that lets it reuse the web's existing load-balancing and security patterns instead of inventing new ones.
A worked example makes the layering concrete. A travel-planning agent uses MCP to read a user's calendar and query a flights API — agent-to-tools. It then needs to actually book, which a specialist booking agent run by a travel provider handles. It reads that agent's signed card over A2A, delegates the booking, and waits for the streamed result. The booking agent, in turn, uses its own MCP connections to payment and inventory systems. MCP and A2A interleave; at no point does one substitute for the other.
Real-World Applications
A2A's adoption is what makes it more than a proposal. Within its first year — measured to April 2026 — the Linux Foundation reported over 150 supporting organizations, more than 22,000 GitHub stars, and production SDKs in five languages (Python, JavaScript, Java, Go, and .NET). It reached general availability inside Microsoft Copilot Studio and Azure AI Foundry, and gained support through Amazon Bedrock AgentCore.
Concretely, enterprises use A2A to coordinate autonomous systems across vendor boundaries in supply chain, financial services, insurance, and IT operations — settings where the agent doing the planning and the agent doing the specialized work belong to different companies and must interoperate without a custom, one-off integration for each pair. This is the same problem multi-agent systems have always faced; A2A standardizes the wire so the N × M integration explosion collapses.
Challenges
The hardest problems in A2A are not about moving messages — they are about trust and coordination between parties that do not share an owner.
- Verifying who you are delegating to. Signed Agent Cards exist precisely because an unsigned capability claim is an attack surface: an agent that lies about what it does, or impersonates a trusted provider's domain, can be handed real work. Identity is a security decision before it is an engineering one, which is why related efforts like DNS-based agent identity and the Agent Payments Protocol (AP2) are converging on the same problem from other directions.
- Failure and cost across a boundary. When a remote agent takes an hour, fails halfway, or bills for the compute it burned, the delegating agent must handle timeouts, retries, and accountability for work it did not perform and cannot see inside. A blocking function-call model does not survive this; A2A's streaming, task-oriented design is a response to it.
- Knowing when not to use it. If the agents in your system are really components you control, a direct call is simpler and cheaper than a discovery-and-delegation protocol. A2A earns its complexity only when the peer is genuinely independent — a different team, a different vendor, discovered at runtime.