A research paper published on arXiv in late June 2026 ran every major agent interoperability protocol - MCP, A2A, ACP, ANP, and ERC-8004 - through a governance taxonomy and found that voting and dissent preservation are universally absent across all five protocols, and deliberation is absent or at most partial. That finding matters because A2A just crossed its biggest institutional milestone: v1.0, under Linux Foundation governance, with confirmed production deployments from Google, Microsoft, and AWS. The spec is stable. The governance primitives are not.
That tension is worth understanding if you're building or buying any multi-agent system right now.
What the A2A protocol actually does
A2A extends the idea behind MCP, which mainly connects an agent to tools or APIs. While MCP focuses on the agent-to-tool relationship, A2A generalizes it to agent-to-agent collaboration. The practical gap it fills: 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.
Agent Cards serve as a discovery mechanism through which each agent publishes a machine-readable description of its capabilities, input and output modalities, and authentication requirements. Tasks represent units of work with a defined lifecycle, progressing through states such as submitted, working, input-required, completed, canceled, and failed, and carrying structured payloads that can include text, files, and structured data.
It is built on existing common standards, including Server-Sent Events, HTTP(S), JSON-RPC, and OAuth 2.0 for mutual agent authentication without sharing credentials; it also uses JSON Web Tokens for compacting and signing tokens. Nothing exotic. That's deliberate - the spec rides infrastructure every engineering team already operates.
What v1.0 actually changed
A2A v1.0 is the version that turned the spec into something production-grade. The four changes are concrete:
The most important is Signed Agent Cards. By adding a cryptographic signature to the Agent Card, a receiving agent can verify that the card was actually issued by the domain owner. Without this, an attacker could stand up a fake Agent Card and redirect other agents into a card forgery attack. Signed Agent Cards are effectively the trust model that makes decentralized discovery viable at all.
The second change is multi-tenancy: a single endpoint can now host multiple agents, letting SaaS providers serve different agents per tenant. The third is multi-protocol bindings: the same logical agent can be exposed over both JSON-RPC and gRPC. The fourth is version negotiation, which spec-level guarantees backward-compatible migration from v0.3.
The v1.0 milestone marks the transition from vendor-controlled specification to industry-governed standard - with 150+ member organizations and confirmed production implementations from Microsoft, Amazon Web Services, and Google.
One number worth sitting with: at 5 conversation rounds, A2A uses 7% more tokens than session-aware alternatives, with 20% of its tokens being overhead from re-transmitted context. At 10 rounds, the gap widens to 23% more tokens, with 39% of tokens being pure overhead.
This scaling pattern confirms the protocol design prediction: stateless re-invocation incurs overhead that grows with conversation length, because each round must re-send all prior context. For short, discrete delegations this doesn't matter. For long-running agent conversations - think a research agent that checks in with a writing agent across ten turns - it adds up fast.
On the other side of the ledger: A2A auth protocol overhead is less than 0.13% of total end-to-end latency even at p99. LLM inference dominates by three orders of magnitude. The protocol layer is not your bottleneck. Your inference calls are.
The ACP merger and what it means for the field
For a brief period in mid-2025, teams had a real choice between two agent-to-agent protocols. IBM Research launched the Agent Communication Protocol (ACP) in March 2025 to power its BeeAI Platform. Later that month, the BeeAI project - and with it, ACP - was donated to the Linux Foundation.
Whereas A2A leaned into enterprise-grade richness, ACP focused on simplicity, developer-friendliness, and cross-framework neutrality.
In September 2025, IBM announced that ACP would officially merge with A2A under the Linux Foundation. This wasn't an abandonment - it was a recognition that maintaining two agent-to-agent standards created unnecessary fragmentation.
The ACP team is winding down active development and contributing its technology and expertise to A2A.
If you're starting fresh in 2026, ACP is historical context, not a current decision. The consolidation is effectively complete.
Beagle in action#engineering, 11:02amWhere the real gaps are
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.
The deeper gap is governance. AWS Bedrock AgentCore - generally available in 15 regions - provides a production agent registry with semantic search, A2A Agent Cards, Cedar-based authorization, lifecycle management, and CloudTrail audit, yet encodes no trust scoring, behavioral reputation, capability verification, or governance primitives.
The governance gap is not merely a research finding; it affects deployed enterprise systems serving production agent fleets.
What this means practically: right now, an orchestrator agent deciding which specialist to delegate to has no protocol-native way to know whether that specialist has a history of failures, whether it's behaving within its declared scope, or whether its Agent Card was issued by who it claims. You build those trust layers yourself, in application code, per deployment. That's where teams are spending the engineering time that A2A didn't save them.
Retry logic and circuit-breaking are deliberately left to the client implementation; the protocol focuses on state and message communication. That's a reasonable design choice for a general spec, but it means every team operating A2A in production is rebuilding the same resilience layer from scratch.
Teams adopting A2A typically start by mapping which parts of their workflow genuinely benefit from specialist agents, since the protocol adds coordination overhead that is not worth paying for simple single-step tasks. That filter is more useful than any benchmark table. If a single agent with tool calls can do the job, the protocol layer is pure overhead. Where A2A earns its keep is cross-organization delegation - an external compliance agent that your internal orchestrator needs to invoke without a pre-negotiated integration agreement.
A colleague-type tool like Beagle fits naturally into this layer: when a coordinator agent delegates a Slack-channel lookup or a thread-summary task, having a standardized handoff means the orchestrator doesn't need to know how the Slack-side work gets done.
Agent-to-agent protocol: common questions
What is the A2A protocol and how does it differ from MCP?
A2A extends MCP's model: where MCP connects an agent to tools or APIs, A2A generalizes it to agent-to-agent collaboration. MCP answers "what can this agent do with external tools." A2A answers "how do two agents discover each other, negotiate auth, and hand off work" - including across organizational and vendor boundaries.
Is A2A v1.0 ready for production use?
The v1.0 stability signal changes the calculation. A v1.0 release under Linux Foundation governance with production deployments from three major cloud providers is a different technical maturity signal than a v0.x specification from a single vendor. The risk profile of adopting A2A now is measurably lower than it was at launch. That said, application-level gaps around governance, token downscoping, and registry standardization still require custom engineering.
What happened to ACP (IBM's Agent Communication Protocol)?
ACP has merged with A2A under the Linux Foundation. The ACP team is winding down active development and contributing its technology and expertise to A2A. Users of ACP are advised to refer to the official migration paths and documentation for transitioning to A2A.
Does A2A add meaningful latency to agent calls?
No - A2A protocol overhead is less than 0.13% of total end-to-end latency even at p99. LLM inference dominates by three orders of magnitude. The token overhead from stateless context re-transmission is a more real concern for multi-round agent conversations than the protocol layer itself.
What governance capabilities does A2A v1.0 still lack?
Voting and dissent preservation are universally absent across all five major protocols, and deliberation is absent or at most partial. More practically for most teams: trust scoring, behavioral reputation, and capability verification are all absent from the spec. At the observed evolution velocity, researchers estimate the governance gap could narrow significantly within 6-12 months through protocol extensions, particularly via A2A's extension mechanism.