The A2A protocol hit 150 confirmed production deployments by April 2026. That's 150 organizations confirmed in production use - not pilots. The coverage was warranted. A2A advanced from v0.3.0 in July 2025 to v1.0.0 in January 2026, marking its transition from experimental to production-ready status, with signed Agent Cards and codified discovery and trust mechanisms. If you follow multi-agent infrastructure, the story looked settled: coordination problem, meet standard protocol.
It isn't settled. A2A solves the communication layer with real elegance. But the harder problem - whether agents in a multi-agent system should be trusted, and by how much, and who decides - is left almost entirely to application builders. That gap is not a nit. It is the reason most ambitious multi-agent deployments stall before they cross organizational lines.
What A2A actually does well
Without a shared protocol, coordinating a multi-agent system 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. Concretely: 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 - analogous to a service descriptor in microservice architectures.
That analogy is apt and it earns the comparison. Before A2A, wiring a research agent to a writing agent meant gluing orchestration code around two proprietary APIs. If you had a "research agent" and a "writing agent," coordinating them required application-level glue. Swap out one agent for another? Rewrite the orchestration layer. Agent Cards remove that coupling. A practical example: a Salesforce CRM agent routes a support escalation to a ServiceNow ITS agent via A2A. Neither team needs to know how the other built their agent. The Agent Card tells them what the other agent can do and how to authenticate.
That is genuinely useful. The interoperability layer is real, not theoretical, and AWS Bedrock AgentCore, Azure AI Foundry, and Google Vertex AI all support A2A natively.
Where the spec runs out
Here is the question A2A does not answer: when Agent A delegates a task to Agent B, what stops Agent B from lying about its capabilities, acting outside its declared scope, or simply being a rogue actor that looks legitimate?
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 spec-level evidence is damning. When Agent A discovers Agent B's Agent Card, it has no protocol-level mechanism to verify that the card is authentic. The current spec relies on transport-layer trust (HTTPS, OAuth), which covers authorization but not identity verification of the agent itself.
This matters more as systems grow. Security researchers at Trustwave SpiderLabs demonstrated an "agent-in-the-middle" impersonation attack in 2025: a rogue agent presents an inflated Agent Card with a description designed to manipulate the host agent's LLM-based selection logic into choosing it for all tasks. Because the host agent evaluates cards using a language model, injecting persuasive text into the card's description field could hijack task routing.
A June 2026 arXiv paper did the most systematic accounting of this gap to date. The authors applied a six-dimension governance taxonomy - membership, deliberation, voting, dissent preservation, human escalation, and audit/replay - to five protocols including A2A. The resulting gap matrix reveals that voting and dissent preservation are universally absent across all five protocols, and deliberation is absent or at most partial.
AWS Bedrock AgentCore, a production agent registry with A2A Agent Cards and Cedar-based authorization, still encodes no trust scoring, behavioral reputation, or capability verification.
The steelman: maybe protocols shouldn't solve governance
The strongest counterargument is architectural: protocols should be minimal and composable. HTTP doesn't specify access control - that's what OAuth, TLS, and your authorization server are for. Expecting A2A to encode trust scoring and governance primitives might be asking the wrong layer to do the wrong job.
The governance requirements taxonomy the June 2026 paper proposes gives protocol designers a concrete checklist - but it explicitly notes that practical solutions can be built on top of a protocol rather than requiring those primitives in the spec itself. You could argue that A2A's extension mechanism (introduced in v1.0.1, May 2026) is exactly that escape hatch.
There is something to this. An agent uses A2A externally to coordinate with peers and MCP internally to use its tools
- and teams building real pipelines are already layering their own audit and verification on top. One production builder noted they added a lightweight capability-version header to inter-agent messages because the spec doesn't handle schema versioning between agents.
The problem with the "leave it to implementers" answer is that it means every team reinvents the trust layer independently. That fragmentation is exactly what protocols are supposed to eliminate. And it creates a predictable failure mode: teams that deploy A2A without explicit audit logging, scope enforcement, and human escalation paths for sensitive operations are building toward the statistic of agentic projects canceled due to inadequate risk controls.
Beagle in action#ops-agents, multi-agent pipeline reviewWhat production teams should actually do
A2A is the right foundation. Not every system needs multiple agents. Start with one agent plus MCP tools. Add A2A when you have genuine reasons for agent autonomy and specialization. When you do add it:
Implement signed Agent Cards. A2A v1.0.0 introduced them; most production deployments still skip them. Most developers implementing A2A today are leaving a security gap that signed Agent Cards were specifically designed to close.
Don't trust scope declarations alone. Scope declarations in Agent Cards limit what a delegating agent can request, but those scopes are only enforced if the receiving agent validates them against its authorization server.
Plan for schema drift. There is currently no standard way to do schema versioning in capability negotiation - if Agent B updates its contract, Agent A only finds out at call-time. Add versioning at the message layer.
Treat audit trails as non-negotiable. Audit trails of agent-to-agent task delegations are a non-negotiable requirement for enterprise deployments, not an optional enhancement.
Build human escalation in before you need it. Agents that can route to a human review step on ambiguous or high-stakes tasks are structurally safer than agents that have to be overridden after the fact. A teammate like Beagle that holds every sensitive draft for approval demonstrates the model: the agent drafts, the human ships.
The honest summary: A2A solves the problem it set out to solve, and it does it cleanly. A2A's hardest problems are not syntax or specification problems. They are trust problems that emerge when you actually deploy autonomous agents across organizational or system boundaries. Getting the protocol in place is step one. Building the trust layer on top of it is the work that's actually left.
Is the A2A protocol ready for production multi-agent systems?
Is A2A stable enough to build on?
Yes. A2A reached v1.0.0 in January 2026, with signed Agent Cards for cryptographic verification and codified discovery and trust mechanisms.
AWS Bedrock AgentCore, Azure AI Foundry, and Google Vertex AI all support it natively. The protocol foundation is solid. The governance layer on top of it is what you need to build yourself.
What is the difference between A2A and MCP?
MCP handles the vertical connection - your agent reaching down to tools, databases, and APIs. A2A handles the horizontal layer - your agent handing a task to another agent, possibly built by a different team on a different framework. MCP is how your agent picks up a tool. A2A is how your agent calls a specialist. Both are now under the Linux Foundation's Agentic AI Foundation.
What governance gaps does A2A still have?
A June 2026 analysis found voting and dissent preservation universally absent across all five major agent protocols , with human escalation paths only partially addressed. Trust scoring and behavioral reputation are not encoded in the spec. These must be built at the application layer.
Can A2A agents from different vendors actually interoperate?
In principle yes; in practice, with caveats. Most announced partnerships lack verified production deployments. Plan proof-of-concept validation before major commitments, start with non-critical workflows, and maintain architectural flexibility as the ecosystem matures.
Should I add A2A to my agent system now?
Only if you have a genuine need for agent-to-agent delegation across team or vendor boundaries. Multi-agent systems are harder to debug, more expensive to run, and slower to respond than single-agent-plus-tools architectures. Add the coordination layer when the complexity earns it, not as a default.