A year ago, "agent interoperability" was a slide. Google announced the Agent2Agent protocol in April 2025 with roughly fifty partners and a clean pitch: agents shouldn't be islands. One agent should be able to find another, ask what it can do, and hand it a task — even if the two were built by rival companies on incompatible stacks.

Twelve months later the slide has become an institution. A2A was donated to the Linux Foundation, IBM folded its competing Agent Communication Protocol into it, and the one-year tally is north of 150 organizations with native support inside Azure AI Foundry, AWS, and Google's own agent stack. By the usual standards of a year-old open protocol, that is an unambiguous win.

So here is the uncomfortable question worth asking on the anniversary: is anyone actually doing the thing A2A was built for?

What "support" is quietly measuring#

The 150 number is real, but read what it counts. To "support A2A" you publish an Agent Card — a small JSON document at a well-known URL advertising your agent's skills, endpoint, and auth — and you wire up an SDK that speaks A2A's JSON-RPC task format. That's it. It is a low and entirely sensible bar for a standard trying to win a network-effects race. It is also not the same thing as running A2A.

The headline use case — an autonomous agent from Company X discovering an agent it has never met from Company Y and delegating real, money-touching work to it without a human in the loop — is still rare. What's common is the demo's domesticated cousin: A2A used inside one vendor's walls (a Vertex agent calling another Vertex agent), or between two companies that already signed a contract, did a security review, and exchanged credentials the old-fashioned way. That's useful. It is not an open agent economy. It's a better internal bus and a nicer integration format for partnerships that would have happened anyway.

A2A standardized the easy half of agent interop — the message envelope — and the easy half was never what kept agents from collaborating.

The format was never the blocker#

Here's the genuinely non-obvious part, and the ecosystem itself is the evidence. If a shared message schema were the missing piece, A2A's first year would have been about message schemas. Instead the most consequential things built around A2A were a trust layer and a money layer.

Signed Agent Cards arrived because "an agent at a URL says it can issue refunds" is worthless unless you can verify which agent, owned by whom. And the companion Agent Payments Protocol (AP2) — launched with 60-plus payment-industry partners — exists because the instant one agent does real work for another across a company line, someone has to be billed, someone is liable, and someone can be defrauded. Those are the actual obstacles to cross-organizational agent collaboration: identity, authorization, settlement, liability, and recourse when an agent does something dumb with your credit line. A JSON-RPC tasks/send call moves none of them.

This is the same lesson MCP taught in its own lane, inverted. MCP won fast because the hard part of agent-to-tool was mostly inside your own trust boundary — you own the tool, you own the agent, the protocol just had to be good. A2A's hard part is between trust boundaries, which is why the protocol being good is necessary but nowhere near sufficient. (If you're still mapping the lanes, our A2A vs. MCP breakdown and the piece on who actually governs these standards are the companions to this one.)

What to actually do with this in 2026#

None of this means A2A is hype. Consolidating ACP into it and putting it under the Linux Foundation killed a looming standards war, and that alone is worth the year. The practical read for anyone building:

A2A at one year looks less like the arrival of an open agent economy and more like the moment the industry agreed on a common envelope and then discovered, together, that the envelope was never the problem. That's still progress. It's just progress measured in the unglamorous plumbing — signatures, payments, identity — that the next year will actually be about.