A June 2026 paper from arXiv scored five major agent interoperability protocols - MCP, A2A, ACP, ANP, and ERC-8004 - across six governance dimensions. Voting and dissent-preservation were absent in all five. A2A, the current frontrunner, scored 1 out of a possible 12. That number is worth holding in your head while reading everything that follows.
The A2A (Agent-to-Agent) protocol is Google's open standard for letting AI agents from different frameworks discover each other, delegate tasks, and exchange results - without either agent exposing its internal logic. Born as a Google project in April 2025, it's now governed by the Linux Foundation, and as of its one-year mark had crossed 150+ production organisations and 22,000+ GitHub stars, with SDKs in Python, JavaScript, Java, Go, and .NET. That's a real milestone for a protocol that most teams hadn't heard of 18 months ago.
But "150 orgs" deserves scrutiny. That does not mean every claim should be swallowed without skepticism. "Supported by" is not the same thing as "deeply used in production by most developers." Protocol ecosystems often look larger in press releases than they feel in day-to-day engineering work. So: what's genuinely new, what's incremental, and what does the spec leave entirely to you?
What A2A actually does, and why MCP doesn't cover it
While MCP established the standard for connecting individual agents to tools and data sources, MCP was designed for single-agent tool use, not agent-to-agent collaboration. The gap is architectural: MCP describes how one agent reaches out to a tool; A2A describes how one agent reaches out to another agent that has its own ownership, its own toolchain, and its own trust boundary.
A2A standardises communication between AI agents built on different frameworks, enabling them to discover one another's capabilities and collaborate on complex tasks. The spec builds this around four primitives:
Agent Card - a machine-readable JSON description of an agent's capabilities, input/output modalities, and authentication requirements, analogous to a service descriptor in microservice architectures. In v1.0, cards are cryptographically signed by the publisher's domain so callers can verify them before trusting.
Task - a unit of work with a defined lifecycle, progressing through states such as submitted, working, input-required, completed, canceled, and failed, carrying structured payloads that can include text, files, and structured data.
Message - carrying a role of either "user" or "agent" with a body expressed as an array of Parts. Parts can mix text, binary data, files, and structured data, making the protocol multi-modal by design.
Artifact - the output of a completed Task: a PDF, a JSON result, an image - whatever the remote agent produced.
On the wire, A2A uses JSON-RPC 2.0 on top of HTTP, Server-Sent Events, or gRPC bindings. Supported auth methods include API keys, HTTP auth, OAuth 2.0 / OIDC, and mutual TLS - parity with OpenAPI security schemes, which is a pragmatic design choice for enterprise integration.
The official specification defines 11 JSON-RPC methods including SendMessage, SendStreamingMessage, GetTask, SubscribeToTask, and CreateTaskPushNotificationConfig, and both streaming and webhook-based push notifications are baked in from day one.
What v1.0 actually changed (the four things worth reading)
A2A v1.0, released in early 2026, is the version that turned the spec into something production-grade. The v1.0 release notes call out four changes. The most important is Signed Agent Cards.
Agent Cards now ship with a cryptographic signature tied to the publisher's domain. Callers verify the card before trusting capabilities or auth schemes. This is the change that unblocked enterprise procurement - no more "can we trust this Agent Card came from where it claims to?"
The other three changes in v1.0:
Multi-tenancy - a single endpoint can now host multiple agents, letting SaaS providers serve different agents per tenant.
Multi-protocol bindings - the same logical agent can be exposed over both JSON-RPC and gRPC.
Version negotiation - spec-level guarantees backward-compatible migration from v0.3 to v1.0.
v1.2, the current stable release, followed in late March 2026. Version 1.0.1 (May 2026) introduced an extension mechanism supporting "new data, requirements, RPC methods, and state machines."
One consolidation event most coverage missed: in August 2025, IBM's ACP (Agent Communication Protocol) merged into A2A under LF AI & Data. A2A's largest potential competitor joined it voluntarily. That eliminated what had looked like the most viable alternative, making A2A the default path for teams designing inter-agent integration today.
Also new from April 2026: the Agent Payments Protocol (AP2), a sister extension defining how agents authorize, settle, and reconcile payments. AP2 adds verifiable mandates, deterministic settlement receipts, and per-task spend caps. 60+ payments and financial-services organisations are partners at launch.
Where the spec hands the problem back to you
This is the part that most introductory posts skip.
A2A deliberately keeps credential provisioning out of scope to keep the protocol lightweight and allow it to integrate with existing enterprise identity infrastructure. Instead of inventing a new identity system, A2A lets each agent declare what authentication it supports, and credentials are obtained through separate out-of-band processes. This design means the security of any A2A deployment depends entirely on what the implementers put in place.
That's not a criticism - it's a conscious tradeoff. But it has consequences.
A2A uses agent cards to advertise capabilities and declare supported authentication schemes, but it does not mandate how those cards are verified for authenticity. The protocol delegates credential management entirely to implementers, meaning agent impersonation, card tampering, and replay attacks are real risks without additional controls.
The practical operating mode most teams land on: mTLS for everything inside the trust boundary, OAuth 2.0 for everything that crosses it.
There's a deeper structural gap that the spec's extension mechanism can't paper over. A June 2026 arXiv paper (Kang & Diponegoro) applied a six-dimension governance taxonomy - membership, deliberation, voting, dissent preservation, human escalation, and audit/replay - to A2A v1.0.1 and four peer protocols. A2A's extension mechanism explicitly supports "new data, requirements, RPC methods, and state machines." Governance primitives could theoretically be defined as A2A extensions. The key observation: no one has done so. After 6+ months of A2A being publicly available with an active extension ecosystem, zero governance extensions have been proposed or implemented.
The honest read: A2A is excellent at answering "which agent can handle this task and how do I hand it off?" It is not designed to answer "which agent has authority to make this decision, and how do we record a dissent?" Those are different problems, and they're the problems that surface when multi-agent systems stop being demos and start making consequential decisions at scale.
When A2A is the right tool and when it isn't
A2A is not universally useful. The practical reality is that A2A is becoming genuinely valuable in a specific context: where agents are independent systems with their own ownership, tools, and trust boundaries, rather than just internal functions or tool wrappers.
If you're building multi-agent workflows inside a single codebase - a LangGraph graph, a CrewAI crew, a PydanticAI pipeline - you probably don't need A2A yet. Those frameworks already have internal routing. LangChain is a development framework that engineers use to build a single agent by chaining LLMs, tools, and vector databases. A2A lets that LangChain-built application talk securely to an agent built using CrewAI, the OpenAI Agents SDK, PydanticAI, or any other framework that publishes an Agent Card.
The clear use case is cross-boundary delegation:
- A vendor's billing agent handing off a dispute to your refund agent
- An internal triage agent routing to a third-party compliance agent
- An orchestrator at one company delegating research to a specialist agent at another
Vertical adoption spans supply chain, financial services, insurance, and IT operations, where organizations use A2A to coordinate autonomous systems across tools, vendors, and environments.
Where it gets complicated is in teams that want to use A2A as a general-purpose internal message bus. The task state machine is well-designed for long-running async work, but for tight loops with sub-second latency requirements, the overhead of HTTP + JSON-RPC + SSE is measurable. Those workloads are still better served by direct in-process calls or a queue.
Beagle in action#engineering, multi-team incident, 2:41pmA2A protocol: common questions
What is the A2A protocol and how does it differ from MCP?
MCP connects a single agent to its tools and data sources. A2A connects one agent to another agent. MCP is about tool access; A2A is about task delegation across independent systems with separate ownership. Most production multi-agent systems need both: MCP for tool connectivity within an agent, A2A for routing work between agents.
Is A2A stable enough to build on?
v1.2, which followed in late March 2026, is the current stable release. It has SDKs in five languages, production integrations in Microsoft Copilot Studio, Azure AI Foundry, and Amazon Bedrock AgentCore, and a formal deprecation/migration policy. The spec is stable enough for production use. The open question is whether the governance and authorization gaps will remain application-layer problems or get addressed in the spec itself.
Does A2A handle authentication between agents?
Partially.
A2A takes a Web-native approach: an agent publishes an Agent Card served at /.well-known/agent.json, advertising its endpoint, supported skills, and authentication requirements. The card may be signed using JWS, giving a remote caller integrity over the advertised metadata and a cryptographic link to a publisher key.
But the spec does not provision credentials - that's out of scope by design. You own the auth infrastructure; A2A just gives you the handshake mechanism.
How does A2A handle long-running tasks?
Polling GetTask works but creates network strain. The A2A spec resolves this with Server-Sent Events: clients call SendStreamingMessage or SubscribeToTask, the server responds with Content-Type: text/event-stream, and pushes status and artifact update events until the task reaches a terminal state.
For disconnected scenarios, webhook-based push notifications provide the same updates via HTTP POST to a client-provided URL.
What's the biggest thing A2A still doesn't cover?
Governance. Agent interoperability protocols have rapidly matured to enable identity, capability discovery, tool access, and message exchange between autonomous agents. But as enterprises deploy heterogeneous agent fleets that must make collective decisions under governance constraints, the question is: can these protocols support governed agent communities, or only task-oriented coordination? Right now: only task-oriented coordination. Nobody has shipped a governance extension for A2A despite the extension mechanism existing for six months.