A2A is much more popular in enterprise than startups. All of the cloud providers and enterprise orchestration platforms (e.g. Gemini Enterprise, AgentForce, watsonx Orchestrate, SAP Joule) support it. People in enterprise typically make their agents A2A compatible so they can use them on these platforms, share them with other teams, etc.

The startups that I have seen use A2A typically use it for at least one of the following reasons:

1. To standardise their API endpoints. A2A specifies how to send and receive text, data, and files, so they can write client code once and reuse it with different agent frameworks. 2. To standardise agent cataloging. A2A introduces the concept of an Agent Card which contains information about the agent like its name, description, skills, accepted input, etc. 3. For long-running tasks. A2A was explicitly designed for long-running tasks and supports polling, streaming, and webhooks.

Confusingly, none of the above use cases are necessarily agent-to-agent. Turns out to standardise agent-to-agent communication, discovery, and authentication, you need to standardise agent communication, discovery, and authentication.

The A2A protocol is a good (not perfect) solution for agent-to-agent communication and it will continue to grow. How much it grows depends on how agents evolve. At the moment companies are building MCP servers for coding agents and chatbots, but not agents themselves. I believe that companies will eventually start building agents to control and improve their customer's experience. If they do this, A2A is the natural choice because it solves all of the problems associated with discovering, connecting, and communicating with agents over the internet.

Now, discovery is important and there is a post right now on the front page about it. But what everyone is probably missing is that a) agents with tokens and services that honor those tokens is already handled well with HTTP. Fun fact, the original HTTP protocol (does anyone do RFCs anymore?) didn't support POSTs! So, most calls can be boiled down to doing a GET request somewhere with a token the remote end understands. Layer on SSL to hide the ? parameters, assuming it's easy to get certs mapped to your house network.

Discovery can be handled a bunch of different ways but given the nature of where the agents are running, it can be DIFFICULT to connect them (hole poking comes to mind). Of course you could run stuff in the cloud. But, if you care about sovereignty, you probably want to avoid anything that will "lock" you into a service (or a single agent/model for that matter).

What's 100% missing is payments, of course. Meet the 402, PAYMENT REQUIRED. Cloudflare (grumble) has something for that, but they stole it from Lightning Lab's very own roasbeef's Aperture project a while back, which implements payments with the Lightning network.

Make a bulk payment to a Bitcoin address. Stuff it in a Lightning invoice, send it to someone, they extract it and update the server to let you in. If you decided they ripped you off, close the invoice and the funds are refunded.

Now, I know a lot of people are skeptical about Bitcoin, but I really do think micropayments are useful for agent-to-agent comms. That's why I threw down the idea on a page about two years ago...so I wouldn't' forget: https://ahp.nuts.services/

The Agent2Agent Protocol (A2A) - https://news.ycombinator.com/item?id=43631381 - April 2025 (280 comments)

Enterprises have been sold on the idea of Agents talking to each other and performing collaborative work (replacing employees etc) so it makes sense.

From my pov nothing stops me from having a full blown agent _behind_ my MCP server.

So calling agent sees and MCP server, gets list of tools etc. The MCP server spins up an instance of relevant Agent and tells it to maintain state (if needed) as a key back to the calling agent’s MCP session_id.

Trivial stuff on Cloudflare

- gemini-cli can have remote a2a agents connected to it. (See https://github.com/tanaikech/gemini-cli-gas-a2a-subagents and the medium article linked in that repo description.) Haven't tried it but I tried the local use case below.

- can expose a custom Google ADK "agent" via one-liner as a2a, which you can connect to the gemini-cli the same way.

MCP makes things so much easier and faster to release updates/tools to an agent. Yet, not many services support it or support it properly.

I had to write a Claude skill to use API because the service didn't have the MCP tool for that operation.

A2A will be just more of the same. Everything about AI is a work in progress hoping something will work.

I had wanted to use it for my agent "network". A2A didn't fit the use case of "trusted agent, and was bloated due to "what if rogue actor". Of course, I could have used it, with all of its roughness, but chose to just vibe my own (before Claude Teams, though I haven't really used that, I think). In the process of creating a server to handle this (I already set up a Scala webserver to administrate/orchestrate hooks). Would love to hear others' suggestions for this.

So, no.

There's a way higher incentive to build an MCP server than an A2A one, and unless Google makes their default AI search a native A2A client it doesn't feel like it will get the momentum it needs to take off.

It's a common protocol for talking to a host of multiple agents/harnesses.

I think this plays up as we actually deploy more useful agents and need validated agent comms. Should happen soon, early days.

I am not using A2A. I think it is too early for such a thing.