A Slack message arrives: "Can you get the compliance check on that vendor contract and book the legal review if it clears?" One agent in your stack handles document parsing. A different agent, built on a different framework by a different team, owns the calendar and legal queue. Without a shared protocol, somebody writes custom glue code. That glue code is why this is still a manual task for most teams.
That is the exact gap Google's Agent2Agent (A2A) protocol was designed to close.
What the A2A protocol actually does
Google's Agent2Agent (A2A) protocol is an open-source communication standard that enables autonomous AI agents to discover, authenticate, and interact with each other regardless of their underlying implementation or hosting platform. It was released in April 2025 under Apache-2.0 licensing and is now governed by the Linux Foundation.
The cleanest one-line framing comes from the spec itself: MCP is the "USB-C for tool connectivity" (vertical, agent to tool), while A2A is "HTTP for agent collaboration" (horizontal, agent to agent).
That distinction matters practically. In a multi-agent system, you often have a coordinator agent managing the work and specialist agents executing specific tasks. Without a shared protocol, that coordination requires bespoke integration - the coordinator has to know exactly how each specialist works, what inputs it accepts, and how to parse its outputs. A2A standardizes that contract.
Production systems routinely combine both: A2A routes a task to the right specialist agent; MCP gives that agent its context and tools.
The five objects you actually work with
A2A's data model is deliberately small. Every A2A interaction involves five objects: the Agent Card, the Task, Messages, Parts, and Artifacts.
Agent Card.
Any A2A server publishes an AgentCard at /.well-known/agent-card.json declaring its skills, supported MIME types, transport bindings, and security schemes.
Think of it as a machine-readable résumé. A client fetches it before sending anything.
Task. Tasks are the fundamental unit of work in A2A. Each task has a unique identifier and progresses through a defined lifecycle: submitted, working, input-required, auth-required, completed, failed, canceled, or rejected.
That eight-state machine is one of the things that separates A2A from a simple REST call. Sketch a delegated task on a whiteboard and you'd probably draw four states: pending, running, failed, and done. The A2A protocol has eight, because delegated work can stop to wait for more information or can get turned down, and each of those earns a state of its own.
The two "paused" states deserve attention.
A task in input-required pauses until the client sends additional message parts in the same contextId. A task in auth-required pauses until the client supplies the credentials described in the status message.
These make multi-turn, mid-task negotiation a first-class concept rather than an error case.
Messages, Parts, Artifacts. Messages are individual turns. A2A supports three part types: TextPart for plain text, FilePart for binary data (inline or URL-referenced), and DataPart for structured JSON. Artifacts are the outputs the remote agent produces - a document, an image, a structured dataset.
Transport. The spec defines three interchangeable protocol bindings: JSON-RPC 2.0 over HTTP(S), the common default; gRPC for high-throughput internal systems; and HTTP+JSON/REST for teams that think in REST verbs.
For long-running work, clients have three options: polling, streaming via Server-Sent Events, and push notifications via webhook callbacks. No new wire format invented.
Beagle in action#ops-channel, 10:41amWhat v1.0 actually changed - and what it didn't
The protocol advanced from v0.3.0 (July 2025), which introduced streaming-first transport and enhanced Agent Cards with capability negotiation, to v1.0.0 (January 2026), which marked the transition from experimental to production-ready status, introduced Signed Agent Cards for cryptographic verification, and codified the discovery and trust mechanisms identified as gaps in earlier analyses.
Signed Agent Cards provide cryptographic verification of agent identity and metadata, establishing trust before interaction across organizational boundaries.
Multi-tenancy support allows a single endpoint to securely host many agents.
A2A v1.0 aligns with core architectural principles of the web: stateless, layered architecture, standard protocol bindings, and infrastructure-friendly communication patterns. That alignment matters operationally because organizations can scale agent interactions with the same proven load balancing, gateway, security, and observability patterns they already use for web systems.
But be precise about what Signed Agent Cards actually prove. A signature confirms who issued the card. It does not confirm that the data behind the agent is certified, current, or consistently defined. Authenticity is not correctness, and it is not shared meaning.
| MCP | A2A | |
|---|---|---|
| Layer | Vertical (agent → tool) | Horizontal (agent → agent) |
| Discovery | Manual host config | Agent Card at /.well-known/ |
| Interaction model | Stateless function calls | Stateful tasks with lifecycle |
| Long-running work | Not native | Eight-state task machine, SSE streaming |
| Auth | Per-server | OAuth 2.0, mTLS, Signed Cards (v1.0) |
| Typical user | Single agent accessing data | Multi-agent systems, cross-org workflows |
The adoption gap nobody is talking about
The headline numbers look healthy. More than 150 organizations participate, the GitHub repo has passed 22,000 stars, and production deployments now exist inside Azure AI Foundry and Amazon Bedrock AgentCore.
Microsoft integrated it into Azure AI Foundry and Copilot Studio. AWS added support through Amazon Bedrock AgentCore Runtime. Google, as the protocol's originator, baked it into Vertex AI.
But a GitHub issue filed in April 2026 from an agent interoperability research team offers a sharper number. They probed 50 agents from multiple agent directories that explicitly advertised A2A endpoint support in their registry listings. The finding: near-zero real-world compliance despite widespread endpoint advertisement. The question they raised was whether the 0-4% figure is consistent with other operators' experience, and whether A2A will eventually require conformance testing or whether self-declaration is sufficient.
Many AI agent demos in 2025 did not need A2A at all. They needed better prompts, better tools, better permissions, better retry logic, and better logs.
Adopt A2A when you genuinely have multiple agents that must interoperate across teams, frameworks, or organizations - which is a later stage than most projects admit.
Architects should still expect to engineer application-level workarounds for gaps including per-skill body schemas, token downscoping, and registry standardisation - but the protocol itself is no longer a moving target.
Agent-to-agent protocol A2A: common questions
What is the A2A protocol and how is it different from MCP?
A2A (Agent2Agent) is an open protocol for one AI agent to discover, delegate work to, and receive results from another AI agent - across different frameworks and vendors. MCP (Model Context Protocol) connects a single agent to external tools and data sources. MCP is vertical; A2A is horizontal. Most real multi-agent systems need both layers.
What is an Agent Card in A2A?
An Agent Card is a JSON document published at /.well-known/agent-card.json by every A2A-compliant agent. It declares the agent's skills, accepted input formats, output types, transport bindings, and authentication requirements. A client fetches the card before sending any work, so no out-of-band configuration is needed to discover what a remote agent can do.
Is A2A production-ready?
A2A v1.0 shipped in early 2026 with Signed Agent Cards, multi-tenancy, and web-standard transport bindings. It is integrated into Azure AI Foundry, Amazon Bedrock AgentCore, and Google Vertex AI. That makes it production-viable inside enterprise boundaries. Cross-organization use at internet scale - where shared registries and trust models matter - is still maturing.
How do A2A and MCP work together in a multi-agent system?
A coordinator agent uses A2A to discover and delegate a task to the right specialist agent. That specialist agent then uses MCP to pull context from a knowledge base, query a database, or call an API tool. A2A routes the work to the right agent; MCP gives that agent what it needs to execute. The two protocols occupy different layers and do not compete.
When should a team skip A2A and just use MCP?
If your agents all live inside a single framework or a single team's codebase, A2A adds overhead without meaningful benefit. A single agent calling tools through MCP servers is simpler to build, debug, and maintain. A2A earns its keep when agents are genuinely independent systems - separate ownership, separate deployment, separate trust boundaries - that need to delegate work to each other without custom integration code.