Rendered at 22:06:28 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
calny 2 hours ago [-]
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
david_shi 1 hours ago [-]
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.
inickt 43 minutes ago [-]
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.
lazharichir 2 hours ago [-]
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.
asim 1 hours ago [-]
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.
winwang 1 hours ago [-]
(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.
thallavajhula 1 hours ago [-]
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'm using it at work as well. It's quite challenging to manage.
siva7 1 hours ago [-]
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.
campak 31 minutes ago [-]
No. I have seen ACP be incredibly helpful in the IDE sense and in things like zo.computer
asdev 1 hours ago [-]
Seems like over engineering just build an API in front of your agent, give the other agent the spec in a markdown file.
pocksuppet 1 hours ago [-]
why dropbox when you can just rsync
dewey 52 minutes ago [-]
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?
dkdcdev 26 minutes ago [-]
you can also put that REST API behind a self-documenting CLI. that’s how I setup my agents to talk to each other
bckr 2 hours ago [-]
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.
reactordev 2 hours ago [-]
Yes. My agent speaks A2A with itself and others. But my agent is built in layers like an organization.
nyellin 2 hours ago [-]
No, it was designed on paper by someone with no understanding of prompt caching and no consideration of latency or token costs
code51 2 hours ago [-]
You mean Google doesn't understand prompt caching, latency or token costs?
Or Google teams fail to communicate for such things?
hypendev 58 minutes ago [-]
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.
kittikitti 1 hours ago [-]
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.
lherron 1 hours ago [-]
I uh…still use tmux send-keys. I’ll change as soon as I find a use-case it doesn’t solve. ¯\_(ツ)_/¯
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.
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.
The Agent2Agent Protocol (A2A) - https://news.ycombinator.com/item?id=43631381 - April 2025 (280 comments)
How is it better than just a REST API with a openapi spec json file?
So, no.
Or Google teams fail to communicate for such things?
"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.
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.