A year ago, Google launched the Agent2Agent protocol with more than 50 technology partners and a promise: AI agents from different vendors and frameworks would finally be able to talk to each other. Twelve months later, the numbers look strong on paper. But the real picture of A2A adoption is messier than the press releases suggest.
Here is what the numbers actually say.
The Official Numbers
The Linux Foundation published A2A’s one-year milestones in April 2026. The headline stats:
| Metric | At Launch (Apr 2025) | One Year (Apr 2026) |
|---|---|---|
| Supporting organizations | 50+ | 150+ |
| GitHub stars | N/A | 22,000+ |
| SDK languages | 1 (Python) | 5 (Python, JS, Java, Go, .NET) |
| Specification status | Draft | v1.0 stable |
| Cloud platform integrations | 0 | 3 (Google, Azure, AWS) |
Those are real numbers. A2A is not vaporware. The specification shipped a stable 1.0 with enterprise features like Signed Agent Cards for cryptographic identity verification, multi-tenancy support, and a web-aligned architecture designed for production load balancing.
All three major cloud providers embedded A2A directly into their platforms. 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. Agent frameworks like LangGraph and CrewAI shipped native A2A support, meaning agents built on different stacks can now delegate subtasks to each other without custom glue code.
The Adoption Gap
But supporter counts and GitHub stars do not tell you how many teams are running A2A in production. That gap matters.
The Linux Foundation announcement referenced “active production deployments across multiple industries,” naming supply chain, financial services, insurance, and IT operations as verticals. What it did not include was the number of production deployments or any usage metrics. Compare that to MCP, which by mid-2026 has thousands of publicly listed servers, an active open-source ecosystem, and measurable developer adoption through tools like Claude Desktop, Cursor, and Windsurf.
A critical analysis from Credal in March 2026 put it bluntly: A2A’s lack of widespread adoption came down to use cases and implementation burden. The protocol advertised capabilities beyond MCP — long-running task management, stateful communication, enterprise security, agent discovery — but many of these features already existed within MCP’s architecture. MCP servers are inherently stateful. They retain context, support multi-turn communication, and handle bidirectional adjustments during task execution.
The result: developers who needed agent-to-tool connectivity chose MCP because it worked in minutes. Developers who needed agent-to-agent coordination often found they could approximate it with MCP’s existing primitives rather than managing a second protocol.
Where A2A Actually Wins
That does not mean A2A is irrelevant. It solves problems MCP was never designed for, and those problems are getting more urgent as agent deployments scale.
Cross-organizational coordination. MCP connects an agent to tools and data sources within a single environment. A2A connects agents across organizational boundaries. When a supply chain agent at one company needs to coordinate with an inventory agent at another, MCP has no answer. A2A does.
Agent discovery. A2A’s Agent Card system gives every agent a machine-readable identity: name, capabilities, supported data types, security requirements. There is no equivalent in MCP. As the number of available agents grows, discovery becomes a first-class problem. The Linux Foundation recently announced an Agent Name Service project to build trusted identity infrastructure on top of this.
Agent payments. The Agent Payments Protocol (AP2), built alongside A2A, enables secure agent-driven transactions with more than 60 organizations already supporting the initiative. As agents move from reading data to spending money, you need a trust layer between agents — there is no way around it. x402 addresses payments at the HTTP level, but AP2 operates at the agent coordination level — different scope, complementary design.
Cryptographic identity. Signed Agent Cards provide cryptographic verification of agent identity, which matters in regulated industries where you need to prove which agent took which action and why. Uber published research on this exact problem in May 2026, describing how they built agent identity and end-to-end provenance for AI systems.
MCP and A2A Are Not Competitors
The Linux Foundation hosts both projects. The A2A 1.0 specification explicitly positions itself as “complementary to MCP, not a replacement.” In practice, the two protocols address different layers:
- MCP connects agents to tools and data sources (agent-to-tool)
- A2A connects agents to other agents (agent-to-agent)
A production multi-agent system will likely use both. An agent uses MCP to query a database, process the results, and then uses A2A to hand a subtask to a specialized agent running on a different framework. The AgentNDX directory tracks MCP servers for the tool layer. The A2A ecosystem is building the coordination layer on top.
Nobody is choosing between A2A and MCP. The question is simpler: does your system need agents talking to other agents? Most teams are still building single-agent workflows. When multi-agent deployments become the norm — and they will — A2A is the protocol waiting on the other side.
What to Watch
Three signals will determine whether A2A crosses from “supported by 150 orgs” to “used by thousands of teams”:
-
Framework defaults. If LangChain, CrewAI, and AutoGen ship A2A as a default communication layer — not an opt-in toggle buried in docs — adoption follows. LangGraph and CrewAI are a start.
-
Agent registries. The Agent Name Service project. Without it, agent discovery stays manual and A2A stays locked inside enterprise environments where teams already know which agents exist.
-
Payment flows. This is the big one. AP2 combined with x402 could create a real economic layer for agent-to-agent transactions. Money follows standards. If AP2 becomes the default for agent payments, A2A adoption rides along.
FAQ
Q: Do I need A2A if I am already using MCP? A: Not yet, unless you are building multi-agent systems that cross organizational boundaries. MCP handles agent-to-tool connectivity. A2A handles agent-to-agent coordination. Most teams start with MCP and add A2A when their agent architecture requires it.
Q: Is A2A production-ready? A: The specification hit v1.0 in early 2026 with SDKs in five languages and integrations across all three major cloud platforms. It is production-ready in the sense that the tooling exists. Whether it is production-proven at scale outside of early enterprise adopters is less clear.
Q: How does A2A relate to other agent protocols like ACP? A: The agent protocol space is fragmented. ACP (Agent Communication Protocol) from IBM, ANP (Agent Network Protocol), and UCP (Universal Commerce Protocol) all target different aspects of agent coordination. A2A has the broadest backing and the most mature specification, but the space is still sorting itself out. Expect mergers and convergence over the next year.