Live data from Hacker News

The Agent2Agent Protocol (A2A)

developers.googleblog.com

281–290 of 293 posts

Re: The Agent2Agent Protocol (A2A)

#281

OK, I’ve read the website, the spec, and JavaScript and python clients and servers. Here’s a quick initial reaction. 1. This is in the “embrace and extend” type area vis-a-vis MCP — if you implemented A2A for a project I don’t think you’d need to implement MCP. That said, if you have an MCP server, you could add a thin layer for A2A compliance. 2. This hits and improves on a bunch of pain points for MCP, with reasona…

Hi there - I work on a2a. Thanks for the reaction - lots of good points here. We really do see a2a as different and complementary to MCP. I personally am working on both and see them in very different contexts.

I see MCP as vital when building an agent. An agent is an LLM with data, resources, tools, and services. However, our customers are building or purchasing agents from other providers - e.g. purchasing "HR Agent", "Bank Account Agent", "Photo Editor Agent", etc. All of these agents are closed systems and have access to private data, APIs, etc. There needs to be a way for my agent to work with these other agents when a tool is not enough.

Other comments you have are spot on - the current specification and samples are early. We are working on many more advanced examples and official SDKs and client/servers. We're working with partners, other Google teams, and framework providers to turn this into a stable standard. We're doing it in the open - so there are things that are missing because (a) its early and (b) we want partners and the community to bring features to the table.

tldr - this is NOT done. We want your feedback and sincerely appreciate it!

Re: The Agent2Agent Protocol (A2A)

#282

OK, I’ve read the website, the spec, and JavaScript and python clients and servers. Here’s a quick initial reaction. 1. This is in the “embrace and extend” type area vis-a-vis MCP — if you implemented A2A for a project I don’t think you’d need to implement MCP. That said, if you have an MCP server, you could add a thin layer for A2A compliance. 2. This hits and improves on a bunch of pain points for MCP, with reasona…

I largely agree with most of this. My only concern is that the spec is a bit underspecified. For example I wish they'd specify the date format more tightly - unix timestamp, some specific ISO format, precision. Which is it? The sessionID is not specified. You can put all sorts of crazy stuff in there, and people will. Not even a finite length is required. Just pick some UUID format already, or specify it has to be an…

(I work on a2a)

Thank you for the feedback? Would you consider writing up an issue on our github with some more specifics? https://github.com/google/a2a

A2A is being developed in the open with the community. You are finding some early details that we are looking into and will be addressing. We have many partners who will be contributing and want this to be a truly open, collaborative endeavor. We acknowledge this is a little different than dropping a polished '1.0' version in github on day 1. But that is intentional :)

Re: The Agent2Agent Protocol (A2A)

#283
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…

Hi there (I work on a2a) - reposting from above.

A2A works at a different level than MCP. We are working with partners on very specific customer problems. Customers are building individual agents in different frameworks OR are purchasing agents from multiple vendors. Those agents are isolated and do not share tools, or memory, or context.

For example, most companies have an internal directory and internal private APIs and tools. They can build an agent to help complete internal tasks. However, they also may purchase an "HR Agent" or "Travel Assistant Agent" or "Tax Preparation Agent" or "Facilities Control Agent". These agents aren't sharing their private APIs and data with each other.

It's also difficult to model these agents as structured tools. For example, a "Tax Preparation Agent" may need to evaluate many different options and ask for specific different documents and information based on an individual users needs. Modeling this as 100s of tools isn't practical. That's where we see A2A helping. Talk to an agent as an agent.

This lets a user talk to only their company agent and then have that agent work with the HR Agent or Travel Booking Agent to complete complex tasks.

Re: The Agent2Agent Protocol (A2A)

#286

A key difference between MCP and A2A that is apparent to me after building with MCP and now reading the material on A2A: MCP is solving specific problems people have in practice today. LLMs need access to data that they weren't trained on, but that's really hard because there's a millions different ways you could RAG something. So MCP defines a standard by which LLMs can call APIs through clients. (and more). A2A sol…

Hi there (I work on a2a) - A2A works at a different level than MCP. We are working with partners on very specific customer problems. Customers are building individual agents in different frameworks OR are purchasing agents from multiple vendors. Those agents are isolated and do not share tools, or memory, or context. For example, most companies have an internal directory and internal private APIs and tools. They can…

While I can logically understand these problems and why A2A could solve them, unfortunately you're asking me to suspend disbelief about the actual agents being built and deployed.

Re: The Agent2Agent Protocol (A2A)

#287

A key difference between MCP and A2A that is apparent to me after building with MCP and now reading the material on A2A: MCP is solving specific problems people have in practice today. LLMs need access to data that they weren't trained on, but that's really hard because there's a millions different ways you could RAG something. So MCP defines a standard by which LLMs can call APIs through clients. (and more). A2A sol…

> I think I can safely say which one will still be around in 6 months LangChain is still around but that doesn't mean much. MCP isn't much better.

I am still simply doing plain fetch requests to LLMs APIs, and it works great, 10/10 would recommend.

Re: The Agent2Agent Protocol (A2A)

#288

Earlier quoted context omitted.

> I think I can safely say which one will still be around in 6 months LangChain is still around but that doesn't mean much. MCP isn't much better.

Langchain has long solved (we can argue on if it's done it well, opinions vary) the problem of needing to orchestrate LLM calls into a coherent workflow. Plus it had a first mover advantage. MCP solves a data and API integration problem. Both are concrete things that people need to do today . AI agents talking to one another is not a concrete problem that organizations building features that integrate AI have today.

> the problem of needing to orchestrate LLM calls into a coherent workflow.

I didn't feel the need to use Langchain, chaining LLM calls is usually just a few lines of code (I think even fewer than when using Langchain).

Re: The Agent2Agent Protocol (A2A)

#290
Reading through the documentation, I get a sense that the "agent" server could be any application that exposes an agent card and follows the protocol. Doesn't really have to be using LLM or be "agentic" (guess that's where the agent black box) comes in.
Post reply on HN