A year ago, Google announced the Agent2Agent (A2A) protocol with a straightforward premise: agents built on different frameworks by different vendors need a common language to discover each other, negotiate tasks, and coordinate across organizational boundaries. The announcement was light on implementation details and heavy on ambition. One year later, the protocol has real adopters, real cloud platform support, and — according to the Linux Foundation’s latest tracking — production enterprise deployments that weren’t there six months ago.
The milestone worth noting isn’t just the headcount. It’s the shape of the adoption.
The Numbers That Actually Matter
The April 9, 2026 one-year anniversary press release from PR Newswire laid out the core metrics: 150+ organizational adopters, landing in major cloud platforms, and enterprise production use in the first year. But the more instructive data point is the trajectory: the protocol went from launch (April 2025) to 100+ companies by June 2025, then added 50 more in the subsequent ten months. That’s a doubling in two months followed by a year of steady enterprise-grade expansion — not a hype curve that crashed.
The Linux Foundation took over stewardship, which matters for long-term protocol stability. When a Google-announced protocol gets donated to a neutral foundation within the first year, it signals that the intent is infrastructure, not vendor lock-in. The DeepLearning.AI course on A2A, built in collaboration with Google Cloud, is another indicator: training material exists because practitioners are asking for it.
What A2A Actually Does Differently From MCP
The practical question every agent builder asks: when do I reach for A2A versus MCP?
MCP (Model Context Protocol) handles the agent-to-tool connection layer. An agent calls an MCP server to get access to a filesystem, a database, an API — it’s a tool access protocol. MCP servers are typically singleton services that expose capabilities to a single agent.
A2A handles the agent-to-agent connection layer. Two agents, potentially built on different frameworks by different teams, need to negotiate who does what, share context about a shared task, and coordinate a multi-turn conversation. A2A adds the concept of Agent Cards — JSON documents that let an agent discover what another agent can do before attempting to delegate work. This is the capability discovery layer that MCP doesn’t address.
The key architectural insight: a production enterprise agent system in 2026 will use both. MCP for tool access (how agents manipulate the world), A2A for agent coordination (how agents talk to each other). The protocols compose rather than compete.
This is directly relevant to anyone building multi-agent pipelines. A fixed-stage pipeline like the one in ACO System (PM → Architect → Developer → Reviewer) uses A2A principles even without implementing the protocol — each stage is discovering and delegating to the next. The protocol formalizes what a homegrown pipeline does organically.
Agent Cards: The Discovery Problem Solved
The most practically useful part of A2A for multi-agent system builders is Agent Cards. An Agent Card is a machine-readable description of an agent’s capabilities, supported skills, and authentication requirements. When Agent A wants to delegate to Agent B, it queries B’s Agent Card first to determine if B is the right agent for the task.
In practice, this means you can have a directory of agents — a broker pattern — where a coordinator agent queries available agents, reads their cards, and routes tasks based on capability matching. This is fundamentally different from a hardcoded pipeline where each stage is known at design time.
For Aniket’s work with multi-agent systems, the Agent Card pattern is the thing worth studying closely. The formalization of “here’s what I can do, here’s how to authenticate with me” moves capability discovery from compile-time configuration to runtime negotiation.
What Cloud Platform Support Actually Changes
The announcement that A2A landed in major cloud platforms means the protocol has passed the “will this work in a corporate network environment” test. Cloud platform endorsement is a proxy for enterprise IT approval — the kind of sign-off that determines whether a protocol gets through the door at an enterprise with a dedicated platform team.
Google Cloud’s endorsement is particularly notable because A2A was always as much about Google Cloud’s agent ecosystem strategy as it was about open protocol development. Atlassian, Box, Salesforce, and Intuit were early partners — companies with large enterprise footprints whose platform teams needed exactly this kind of interoperability standard.
The Gap Between Announcement and Production
The honest assessment after one year: A2A has crossed the threshold from interesting announcement to production-ready infrastructure. The 150+ organizations number is real. The cloud platform support is real. The production enterprise deployments are real.
What’s still maturing: best practices for Agent Card schema design, authentication patterns for cross-organization agent delegation, and observability tooling for multi-agent conversations that span multiple A2A connections. These are the next layer of tooling that will come as the protocol moves from “we use A2A” to “we use A2A and can debug it when it breaks.”
For anyone building multi-agent systems today, A2A is no longer a research topic. It’s infrastructure you’re likely to encounter — either as something your agents communicate with via an SDK, or as a conceptual pattern (capability discovery + task negotiation + multi-turn coordination) that your own pipeline already implements in some form. Understanding the protocol gives you the vocabulary to name what your system is already doing, and the standards track to know where the ecosystem is heading.
The one-year milestone is less “look how far we’ve come” and more “the baseline is now established.” The interesting work starts here.