Live data from Hacker News

The Agent2Agent Protocol (A2A)

developers.googleblog.com

121–130 of 293 posts

Re: The Agent2Agent Protocol (A2A)

#121
OK, I have to ask: isn't this agents to agents idea kind of Science Fiction?

I absolutely get the value of LLMs calling tools and APIs. I still don't see much value in LLMs calling other LLMs.

Everyone gets really excited about it - "langchain" named their whole company over the idea of chaining LLMs together - but aside from a few niche applications (Deep Research style tools presumably fire off a bunch of sub-prompts to summarize content they are crawling, Claude Code uses multiple prompts executions to edit files) is it really THAT useful? Worth building an entire new protocol with a flashy name and a bunch of marketing launch partners?

LLMs are unreliable enough already without compounding their unreliability by chaining them together!

Re: The Agent2Agent Protocol (A2A)

#123
Agents are already usually deployed as an API service. You can have "agent-to-agent" communication by having agents call each others APIs. I don't understand what this protocol is for.

MCP actually fills a gap since people don't normally expose things like writing to their local filesystem as a callable API.

Re: The Agent2Agent Protocol (A2A)

#124
post #94
post #43

> Hiring a software engineer can be significantly simplified with A2A collaboration. Holy shit.. NO!

See how they didn't choose lawyers, bankers, or government civil servants? Analysts, digital artists, customer service support and journalists of all levels have already been replaced. Software engineers (of all levels) are the next knowledge workers to be replaced by agents.

I was actually more angered about the fact that the hiring process would be further automated, frustrating candidates even more..

Ultimately I see nothing wrong with replacing everyone, providing the newly generated wealth would be distributed to all, not just the select few "owners" of these things.. we'll see..

Re: The Agent2Agent Protocol (A2A)

#125
post #109

I don't totally understand why we need an additional layer of abstraction over MCP at this point. Why can't an agent just be an MCP server? What is the fundamental difference between an MCP server "tool" and an agent "capability"? This kind of feels to me like someone at google saw how successful MCP was becoming and said "we need something like that". I feel the same way about OpenAI's Agent SDK. I think the word "A…

A2A isn't a layer of abstraction over MCP, it functions in parallel and they complement each other. MCP addresses the Agent-to-Environment question, how can Agents "do things" on computers. A2A addresses the Agent-to-Agent question, how can Agents learn about other Agents and communicate with them. You need both. You CAN try and build "the one agent that does everything" but in scenarios where there's many simultaneo…

What is an "agent"?

To my understanding of this protocol it looks like it's an entity exposing a set of capabilities. Why is that different and complementary to an MCP server exposing tools? Why would you be limited to an "everything agent" in MCP?

I am struggling to see the core problem that this protocol addresses.

Re: The Agent2Agent Protocol (A2A)

#126

Earlier quoted context omitted.

It's just another layer of abstraction so one doesn't need to think about HTTP at all, which would bring in irrelevant baggage.

To be fair, HTTP adds a layer of friendliness over TCP (POST/GET, paths, query parameters) and the servers can be so simple that it can hardly be considered irrelevant baggage. The benefit it brings is that you can add debugging endpoints which you can use directly in a browser, you get networking with hosts and ports instead of local-only exe + stdio.

That's just one part of it. Keep in mind MCP supports 3 transport methods: stdio, SSE (which would be your HTTP) and websockets. Irrelevant baggage would be having to consider the workings of any of those (given a decently implemented client+server library), rather than merely declaring the servers, tools, resources and prompts to be accessed. There's also a debug mode I believe.

Re: The Agent2Agent Protocol (A2A)

#127
post #125

Earlier quoted context omitted.

A2A isn't a layer of abstraction over MCP, it functions in parallel and they complement each other. MCP addresses the Agent-to-Environment question, how can Agents "do things" on computers. A2A addresses the Agent-to-Agent question, how can Agents learn about other Agents and communicate with them. You need both. You CAN try and build "the one agent that does everything" but in scenarios where there's many simultaneo…

What is an "agent"? To my understanding of this protocol it looks like it's an entity exposing a set of capabilities. Why is that different and complementary to an MCP server exposing tools? Why would you be limited to an "everything agent" in MCP? I am struggling to see the core problem that this protocol addresses.

Much debated question but if we run with your definition, then A2A adds communication capabilities alongside tool-calling, which is ultimately a set of programmatic hooks. Like "phone a friend" if you don't know the answer given what you have available directly (via MCP, training data, or context).

My assumption is that the initial A2A implementation will be done with MCP, so the LLM can ask your AI directory or marketplace for help with a task via some kind of "phone a friend" tool call, and it'll be able to immediately interop and get the info it needs to complete the task.

Re: The Agent2Agent Protocol (A2A)

#128

Earlier quoted context omitted.

It's just another layer of abstraction so one doesn't need to think about HTTP at all, which would bring in irrelevant baggage.

but at the end of the day MCP is HTTP lol

MCP is a capabilities protocol which uses multiple transport protocols, including HTTP.

Re: The Agent2Agent Protocol (A2A)

#130
This Agent2Agent Protocol (a "compliment" to Anthropic's Model Context Protocol?) seems to me to just be an attempt at a land grab in the line-protocol AI communication ecosystem.

If I'm reading it correctly, A2A is similar to MCP in that they both use JSONRPC but extends the capabilities for agents to be able to communicate with one another, potentially using separate backend models. MCP simply exposes applications data and workflows to a model itself and is not attempting to make agents communicate with one another.

The fact that A2A wasn't proposed as an extension to MCP seems disingenuous at best. To me, it looks like Google (among the other AI giants) is trying to create their own repository of agents, controlling the protocol, thereby enabling them to become the de-facto source for finding trusted agents.

Further, it comes off to me as a defense against the existential threat that AI poses to google's search and ads monopoly.

The problem is, as a consumer of AI, I don't want multiple agents communicating with one another. What I want is one model that communicates with non-agentic services. Making AI work well and understanding what it's doing is hard enough. You now want to pull in multiple models and companies into the picture? Talk about a risk management nightmare.

Shadow IT SaaS is already a massive problem for companies. Now imagine Shadow Agents doing work for your business using A2A to connect dozens of different unsupervised work for the company. No thanks!

For the inevitable defense of A2A "But it's open source and Apache licensed!". That's just bait. If you control the protocol, you control the ecosystem. See: Android, VSCode, Chromium, Java, Kubernetes, etc.

For me? I like my single-model audibility pulling in context using MCP. A2A just seems like an insane attempt at a land grab in the AI agent wars.

Post reply on HN