A year ago, Google announced the Agent2Agent (A2A) protocol at Cloud Next with 50+ partners and the usual launch energy. Twelve months later, the Linux Foundation tracks 150+ organizational adopters, production enterprise use cases, and integration into major cloud platforms. That trajectory is worth examining closely — not because the numbers are impressive on their own, but because they reveal something about how multi-agent systems are actually being built in practice.
What A2A Actually Solves
The protocol’s core problem is one that anyone building multi-agent systems runs into immediately: agents from different vendors, frameworks, or teams can’t coordinate without custom glue code. MCP solved the tool-access problem — how an LLM connects to external tools and data sources. A2A tackles the next layer up: how agents running in different environments discover each other, negotiate tasks, and exchange results.
The mechanism that makes this work is the Agent Card — a JSON document each agent publishes that describes its capabilities, supported skills, and API endpoints. When Agent A needs something Agent B can do, it queries B’s Agent Card to determine compatibility before attempting any hand-off. This sounds simple, but it’s the kind of thing that collapses a lot of custom integration work once you have a standard.
The other core construct is task negotiation: rather than a rigid request-response pattern, A2A agents can exchange multiple messages across a session, maintaining shared context and state as the task evolves. This is what separates it from a simple REST API call.
The Production Adoption Pattern
What’s notable about the adoption is where A2A landed first. According to the Linux Foundation’s April 2026 report, the initial production deployments concentrated in enterprise environments where agents built on different stacks needed to collaborate — Salesforce Agentforce talking to SAP agents, Atlassian’s Atlas AI coordinating with ServiceNow workflows. These are environments where the “build everything in one framework” approach never worked, and the interop problem was already costing real engineering time.
The Google Cloud integration matters here. When a cloud platform adopts a protocol natively, it lowers the adoption barrier for every organization already running on that platform. Agents deployed to Google Cloud can advertise themselves via Agent Cards and participate in A2A negotiations without additional infrastructure work. That’s a different adoption lever than a standalone open-source project.
Where the Gaps Still Are
The anniversary is a good moment to be honest about what A2A doesn’t yet do well.
Security and identity remains the most active area of tension. In a world where agents are exchanging sensitive data across organizational boundaries, the question of who an agent is acting on behalf of — and whether that delegation is authorized — isn’t fully solved by the current spec. The protocol handles transport security (TLS), but the authorization model at the agent level is still being worked through in enterprise deployments.
State management across long-running tasks is another rough edge. A2A’s multi-turn conversation model works well for tasks that complete in seconds to minutes. For tasks that span hours or days — monitoring a pipeline, waiting on external events — the current approach requires agents to maintain state externally (in a database, a message queue), which reintroduces the infrastructure complexity the protocol was meant to abstract away.
Debugging and observability tooling is still nascent. When an A2A negotiation fails, understanding which agent sent what message, where the capability mismatch occurred, and how to replay the interaction is harder than it should be. The Agent Card tells you what an agent claims to support; it doesn’t tell you whether that support is actually working correctly in practice.
What This Means for Multi-Agent Pipeline Design
For anyone building agentic workflows — and Aniket has been thinking about this extensively in the context of the ACO System — A2A’s trajectory is a useful data point on where the industry is actually standardizing.
The pattern that emerges from production adoption is: horizontal coordination between agents is the real unsolved problem. Vertical pipelines (PM → Architect → Developer → Review) are relatively tractable because each stage can be a fixed role with clear inputs and outputs. Horizontal coordination — where agents from different teams, vendors, or infrastructure stacks need to collaborate on a shared task — is where custom code accumulates and where standards like A2A earn their place.
The interesting implication for pipeline design is that a well-designed multi-agent system should be able to absorb A2A as a coordination layer without restructuring its internal stages. An ACO-style fixed pipeline can use A2A to handle the inter-agent communication at its boundaries — when the pipeline needs to delegate to an external agent, or when an external system needs to hand off work to the pipeline — without A2A being the core orchestration mechanism.
The Year Ahead
The anniversary press release from the Linux Foundation signals continued investment: a formal specification process, an Agent Directory to make capability discovery easier, and working groups on security and observability. If those deliver, 2026 could be the year A2A moves from “adopted in principle” to “actually running in production” for a much broader set of organizations.
The protocol has passed the credibility test — it exists, it works, and organizations are using it. The next test is whether it can handle the messy reality of enterprise environments: agents that drift out of sync with their Agent Cards, negotiated tasks that fail partway through and need partial rollback, observability that doesn’t require reading raw JSON logs. That’s where the next year of development will matter most.
Sources: Linux Foundation press release, April 9, 2026; Google Open Source Blog — A Year of Open Collaboration, April 16, 2026; PR Newswire, April 9, 2026