AI infrastructure/tools developer here (www.hic-ai.com). I considered the A2A protocol carefully, but I decided a while ago that, from my perspective, the A2A protocol was not solving the correct problem. There is no distinction (from the perspective of an agent) between a communication from Agent A to Agent B, on the one hand, and a communication from Agent A to "future Agent A", on the other. In fact, agents have no inherent sense of identity at all, so there is no inherent notion of a unique Agent A. The notions like "Agent A" received a message or that "Agent A" is sending a message to a different agent (or to its future self) are all inextricably intertwined with the idea of an agentic identity existing and being well defined in the first place, which it is not. The A2A protocol assumes the existence of such a well-defined agent identity in its presumption that agent cards point to a specific agent that can be discovered and deployed. I also think gRPC adds a significant layer of indirection and obfuscation, plus it's painful to implement. The lack of widespread adoption suggests that A2A is not really solving a real-world problem, compared to MCP, for instance.
We wouldn't have identities either if we were all clones and our memories could be edited and shuffled at each conversation.
For an agent to have an identity we would have to intentionally make it hard to context engineering and limit it to append only messages that mimick human communication.
I can implant a thought into your head. If I say "Don't think about a green elephant" for a moment you'll think about a green elephant. There are more sophisticated examples of a person implanting thoughts in somobodies head (e.g. propaganda) but that's about it, I can't literally edit thoughts.
Why on earth do we want to limit our ability to do more powerful context engineering in a substrate that offers that ability natively?
Presumably because for some use cases you want the context of an agent to belong to a different "administrative domain" and you so want to have control over what information reaches it and how can it affect it?
Not to great effect, AFAIK. Laurie Voss (creator of npm) had a good presentation a few months back on all the different agent interaction protocols, and was skeptical whether they (including A2A) added much value. https://youtu.be/kqB_xML1SfA?si=lxehX1-_z_dBoZtQ
Yes! Although I've created a number of open-source A2A packages (https://github.com/a2anet) so I'm a little biased. For a more objective view, I keep an eye on the A2A SDK's monthly downloads (https://pypistats.org/packages/a2a-sdk). They're at ~10.9M compared to MCP's 257M, so MCP is downloaded about 24x more than A2A.
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.
I am using A2A at work. It's a bit like the "microservices architecture" for agents... Allows you or teams to develop agents independently and have them interact as and when they need to. No major hurdles so far.
This was my assumption. Agents will supersede services. There will be many companies way ahead of the curve and the rest of the industry will take 5-10 years to catch up.
I'm a fan of that phrasing usually but that's not a good comparison in this case I feel. Agents are perfectly fine to use existing REST APIs. I have yet to see the big selling point for MCP as they are usually a very thin layer on top of an existing API just with a formalized description for each tool.
How is it better than just a REST API with a openapi spec json file?
All of this protocol crap is a distraction. What's important is allowing agents talk to each other in their current scope and ACLs, including for their ability to talk to and discover tools. When Anthropic decided MCP was a good idea and published what they did, I ranted for days. Ok, I'm still ranting.
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 "second me" developed by the Chinese team can be checked out (it's open-source and also has commercial products), although I feel they haven't found the corresponding profit point and PMF.
Ya, we tried it a bit, but have stayed with agent-behind-MCP style patterns for now. I think A2A or something like it will become a big thing as everything matures. It just felt over complicated for our use case. One misconception I had was we would just slap A2A on our existing agents and they’d work well together. Kind of dumb in hindsight.
A2A Protocol is directed at enterprises as is much of Google Cloud’s AI focus. They just renamed their AI suite “Gemini Enterprise Agent Platform” if you don’t believe me.
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.
(Based off 2-3 month-old recollection, take with a grain of salt)
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.
If you're big in the google ecosystem it makes sense:
- 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.
We set up something with a registry of AgentCards and a messaging system with SSE streaming—then we realized we didn’t need an agent on the other side so now we have this weird hybrid pattern.
I know our sales/business team is pitching it quite a bit (instead of our current end-to-end solution we provide), but no one has quite been able to define the boundaries of how that interacts when we don't own the full solution. Curious how others have been using it. Definitely seems designed for more of an internal or B2B use case where agents have super well defined behavior but are ultimately behind some other system entirely.
I've changed my mind a few times on this, but given how substantial the adoption for MCP has been (Claude and OpenAI both use it for their native integrations) its only a matter of time before consolidation happens.
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.
A2A solves the problem of independently developed agents talking to each other. The bigger problem is "how do i trust your agent works?", which would be solved by having a believable system of Agent Evals, so I could test that your Agent actually does what it says on the box. Otherwise an Agent Directory and automatic dispatch of agents is close to useless.
In the past 1 year, I think I've moved from MCP to A2A to Agent <> MCP back again. I have agents still talking to other Agents via A2A for some use cases, but for the most part, it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.
I work at some megacorp and have direct insight about any ai use - nope, not a single use case i witnessed used a2a in the final product. I still don't get a2a but you probably have to work at Google or something to see this as the solution to something.
"Google" doesn't understand anything, as it isn't one being.
Google has also as many average employees as any other company, and they will also come up with bad, corporate, ideas.
Honestly the worst part about the LLM age is that everyone is suddenly an "expert", and that is why we get shitty things like A2A or MCP or whatever the next "shiny" overengineered thing is.
Just like with any new technology, people will crawl out the woodwork to establish "standards" just so they can claim fame, money and attention that comes with it.
A2A is a very high level protocol that's meant to be an entry point for the actual network protocols that allow agents to communicate with others like HTTP, gRPC, and others. The promise of no-code means the concept has to exist as an abstraction.
There's a Kaggle course going on where Google discusses A2A and their thoughts on it. If you're a pure vibe coder who doesn't know how to code, A2A is for you. If you know the basics of programming and could even do some web crawling, there are many accessible options.
Google and the industry is honing in on these vibe coders who will look at 10 million tokens consumed to make a checklist application and think nothing of it. The agent to agent (A2A) protocol is for them. Personally, I think it's useful to describe what I'm already doing to people who aren't experts.
AI infrastructure/tools developer here (www.hic-ai.com). I considered the A2A protocol carefully, but I decided a while ago that, from my perspective, the A2A protocol was not solving the correct problem. There is no distinction (from the perspective of an agent) between a communication from Agent A to Agent B, on the one hand, and a communication from Agent A to "future Agent A", on the other. In fact, agents have no inherent sense of identity at all, so there is no inherent notion of a unique Agent A. The notions like "Agent A" received a message or that "Agent A" is sending a message to a different agent (or to its future self) are all inextricably intertwined with the idea of an agentic identity existing and being well defined in the first place, which it is not. The A2A protocol assumes the existence of such a well-defined agent identity in its presumption that agent cards point to a specific agent that can be discovered and deployed. I also think gRPC adds a significant layer of indirection and obfuscation, plus it's painful to implement. The lack of widespread adoption suggests that A2A is not really solving a real-world problem, compared to MCP, for instance.
We wouldn't have identities either if we were all clones and our memories could be edited and shuffled at each conversation.
For an agent to have an identity we would have to intentionally make it hard to context engineering and limit it to append only messages that mimick human communication.
I can implant a thought into your head. If I say "Don't think about a green elephant" for a moment you'll think about a green elephant. There are more sophisticated examples of a person implanting thoughts in somobodies head (e.g. propaganda) but that's about it, I can't literally edit thoughts.
Why on earth do we want to limit our ability to do more powerful context engineering in a substrate that offers that ability natively?
Presumably because for some use cases you want the context of an agent to belong to a different "administrative domain" and you so want to have control over what information reaches it and how can it affect it?
Agent identity is just OAuth in a fake mustache. I suspect the real boundary is not agent-to-agent, but context + permissions + audit trail.
Not to great effect, AFAIK. Laurie Voss (creator of npm) had a good presentation a few months back on all the different agent interaction protocols, and was skeptical whether they (including A2A) added much value. https://youtu.be/kqB_xML1SfA?si=lxehX1-_z_dBoZtQ
Yes! Although I've created a number of open-source A2A packages (https://github.com/a2anet) so I'm a little biased. For a more objective view, I keep an eye on the A2A SDK's monthly downloads (https://pypistats.org/packages/a2a-sdk). They're at ~10.9M compared to MCP's 257M, so MCP is downloaded about 24x more than A2A.
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.
I am using A2A at work. It's a bit like the "microservices architecture" for agents... Allows you or teams to develop agents independently and have them interact as and when they need to. No major hurdles so far.
This was my assumption. Agents will supersede services. There will be many companies way ahead of the curve and the rest of the industry will take 5-10 years to catch up.
Why would an agent supersede a service for a well-defined workflow contract that does not require an agentic loop? I assume both will need to exist.
Related. Others?
The Agent2Agent Protocol (A2A) - https://news.ycombinator.com/item?id=43631381 - April 2025 (280 comments)
On the vscode team we're rebuilding our agent infrastructure on top of a new protocol, AHP: https://github.com/microsoft/agent-host-protocol.
It's a common protocol for talking to a host of multiple agents/harnesses.
Seems like over engineering just build an API in front of your agent, give the other agent the spec in a markdown file.
why dropbox when you can just rsync
I'm a fan of that phrasing usually but that's not a good comparison in this case I feel. Agents are perfectly fine to use existing REST APIs. I have yet to see the big selling point for MCP as they are usually a very thin layer on top of an existing API just with a formalized description for each tool.
How is it better than just a REST API with a openapi spec json file?
you can also put that REST API behind a self-documenting CLI. that’s how I setup my agents to talk to each other
I wouldnt generalize it like that. Its a real position and viable option.
One thing I keep noticing in these discussions is that we spend a lot of time on communication protocols and not much on authority.
If my agent discovers your agent and asks it to do something, how does your side know:
who delegated that authority?
what it's allowed to do?
whether that authority has been revoked?
Communication seems solvable.
Trusting the action feels much harder.
All of this protocol crap is a distraction. What's important is allowing agents talk to each other in their current scope and ACLs, including for their ability to talk to and discover tools. When Anthropic decided MCP was a good idea and published what they did, I ranted for days. Ok, I'm still ranting.
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 "second me" developed by the Chinese team can be checked out (it's open-source and also has commercial products), although I feel they haven't found the corresponding profit point and PMF.
Ya, we tried it a bit, but have stayed with agent-behind-MCP style patterns for now. I think A2A or something like it will become a big thing as everything matures. It just felt over complicated for our use case. One misconception I had was we would just slap A2A on our existing agents and they’d work well together. Kind of dumb in hindsight.
Yes. My agent speaks A2A with itself and others. But my agent is built in layers like an organization.
Would love to hear more if you're interested in sharing.
.
A2A Protocol is directed at enterprises as is much of Google Cloud’s AI focus. They just renamed their AI suite “Gemini Enterprise Agent Platform” if you don’t believe me.
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
(Based off 2-3 month-old recollection, take with a grain of salt)
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.
If you're big in the google ecosystem it makes sense:
- 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.
Gemini CLI is deprecated and replaced by antigravity-cli
I'm using it at work as well. It's quite challenging to manage.
We set up something with a registry of AgentCards and a messaging system with SSE streaming—then we realized we didn’t need an agent on the other side so now we have this weird hybrid pattern.
So, no.
I know our sales/business team is pitching it quite a bit (instead of our current end-to-end solution we provide), but no one has quite been able to define the boundaries of how that interacts when we don't own the full solution. Curious how others have been using it. Definitely seems designed for more of an internal or B2B use case where agents have super well defined behavior but are ultimately behind some other system entirely.
I've changed my mind a few times on this, but given how substantial the adoption for MCP has been (Claude and OpenAI both use it for their native integrations) its only a matter of time before consolidation happens.
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.
A2A solves the problem of independently developed agents talking to each other. The bigger problem is "how do i trust your agent works?", which would be solved by having a believable system of Agent Evals, so I could test that your Agent actually does what it says on the box. Otherwise an Agent Directory and automatic dispatch of agents is close to useless.
A2A when MCP is not even adopted properly.
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.
In the past 1 year, I think I've moved from MCP to A2A to Agent <> MCP back again. I have agents still talking to other Agents via A2A for some use cases, but for the most part, it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.
I had the same question in mind while reading another submission on the front page: https://news.ycombinator.com/item?id=48573268
I am not using A2A. I think it is too early for such a thing.
I work at some megacorp and have direct insight about any ai use - nope, not a single use case i witnessed used a2a in the final product. I still don't get a2a but you probably have to work at Google or something to see this as the solution to something.
No. I have seen ACP be incredibly helpful in the IDE sense and in things like zo.computer
I uh…still use tmux send-keys. I’ll change as soon as I find a use-case it doesn’t solve. ¯\_(ツ)_/¯
Not really.
I think this plays up as we actually deploy more useful agents and need validated agent comms. Should happen soon, early days.
I tried making a port of buttplug-mcp called a2a4a2a.
enterprises are, its the future for them. Take a look: https://www.tigera.io/blog/why-we-built-lynx-bringing-contro...
No, it was designed on paper by someone with no understanding of prompt caching and no consideration of latency or token costs
You mean Google doesn't understand prompt caching, latency or token costs?
Or Google teams fail to communicate for such things?
This is kind of a loaded question.
"Google" doesn't understand anything, as it isn't one being. Google has also as many average employees as any other company, and they will also come up with bad, corporate, ideas.
Honestly the worst part about the LLM age is that everyone is suddenly an "expert", and that is why we get shitty things like A2A or MCP or whatever the next "shiny" overengineered thing is.
Just like with any new technology, people will crawl out the woodwork to establish "standards" just so they can claim fame, money and attention that comes with it.
A2A is a very high level protocol that's meant to be an entry point for the actual network protocols that allow agents to communicate with others like HTTP, gRPC, and others. The promise of no-code means the concept has to exist as an abstraction.
There's a Kaggle course going on where Google discusses A2A and their thoughts on it. If you're a pure vibe coder who doesn't know how to code, A2A is for you. If you know the basics of programming and could even do some web crawling, there are many accessible options.
Google and the industry is honing in on these vibe coders who will look at 10 million tokens consumed to make a checklist application and think nothing of it. The agent to agent (A2A) protocol is for them. Personally, I think it's useful to describe what I'm already doing to people who aren't experts.