Live data from Hacker News

The Agent2Agent Protocol (A2A)

developers.googleblog.com

161–170 of 293 posts

Re: The Agent2Agent Protocol (A2A)

#161

How it claims to complement/differentiate from MCP here: https://google.github.io/A2A/#/topics/a2a_and_mcp Basically (google claims): MCP enables agents to use resources in a standard way. A2A enables those agents to collaborate with each other.

I suppose Google wants us to pretend that "agents" can't be "resources." MCP is already well established (Anthropic, OpenAI, Cursor, etc), so Google plastering their announcement with A2A endorsements just reeks of insecurity.

I figure this A2A idea will wind up in the infamous Google graveyard within 8 months.

Re: The Agent2Agent Protocol (A2A)

#162
post #65

Earlier quoted context omitted.

> so they can sell it back to you via “search.” > transfer your private textual data to them Who is "they" (or "them") in these sentences? It's an open protocol with 50 partner companies, which can be used with AI agents from ~anyone on ~any framework. Presumably you can use this protocol in an air-gapped network, if you'd like. Which one of the 50 partner companies is taking my data and building the moat? Why would…

I think the point the above poster is trying to make is that the point here is that they don't want to share the data. Instead google (and atlassian/SAP/whoever) would like to make an "open" but limiting interface mediated through their agents, such that you can never get actual access to the data, but only what they decide you get to have. To put it bluntly, the point of creating the open interface at this level, is…

Yes that’s exactly the point

Open the interface publicly then monetize the I/O or storage or processing.

Classic high margin SaaS approach with a veneer of “open.”

You can look at it as a standards capture

Re: The Agent2Agent Protocol (A2A)

#163
post #160
post #19

I just published some notes on MCP security and prompt injection. MCP doesn't have security flaws in the protocol itself, but the patterns it encourage (providing LLMs with access to tools that can act on the user's behalf while they also may be exposed to text from untrusted sources) are rife for prompt injection attacks: https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/

Feels critical right now to sandbox mcps in containers while the security side of things catches up.

This might be what you mean, but for anyone reading -- the point of Simon's article is the whole agent and all of its tools have to be considered part of the same sandbox, and the same security boundary. You can't sandbox MCPs individually, you have to sandbox the whole system together.

Specifically the core design principal is you have to be comfortable with any possible combination of things your agent can do with its tools, not only the combination you ask for.

If your agent can search the web and can access your WhatsApp account, then you can ask it to search for something and text you the results -- cool. But there's some possible search result that would take over its brain and make it post your WhatsApp history to the web. So probably you should not set up an agent that has MCPs to both search the web and read your WhatsApp history. And in general many plausibly useful combinations of tools to provide to agents are unsafe together.

Re: The Agent2Agent Protocol (A2A)

#164
post #38

Earlier quoted context omitted.

Every decade or so we just forget that in-band signaling is a bad idea and make all the same mistakes again it seems. 1960s phone companies at least had the excuse of having to retrofit their control systems onto existing single-channel lines, and run the whole operation on roughly the processing power of a pocket calculator. What's our excuse?

> What's our excuse? There exist no such thing as "out-of-band signaling" in nature. It's something we introduce into system design, by arranging for one part to constrain the behavior of other, trading generality for predictability and control. This separation is something created by a mind, not a feature of the universe. Consequently, humans don't support "out-of-band signalling either . All of our perception of re…

Today’s LLMs are not humans and don’t process information anything like humans.

Re: The Agent2Agent Protocol (A2A)

#165
post #80

Earlier quoted context omitted.

Enterprise databases are filled with users usurping a field with pre/post-pending characters to mean something special to them. Even filenames have this problem due to limitations in directory trees. Inband signals will never go away.

At some level everything has to go in a single band. I don't have separate network connections to my house, I don't send separate TCP SYN packets for each "band". I don't have separate storage devices for each file on my harddrive. We multiplex the data somewhere. Yhe trick to it is that the multiplexer has to be a component, and not a distributed set of ad-hoc regexes.

at some level, sure, but I can no longer put

    +++ATH0
into my comment and have it hang up your connection, so it's worth some effort to prevent the problem.

Re: The Agent2Agent Protocol (A2A)

#166
post #154

Earlier quoted context omitted.

the architecture astronauts are back at it again. instead of spending time talking about solutions, the whole AI space is now spending days and weeks talking about fun new architectures. smh https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit

There's a simple reason for that. AI (real AI) is now an engineering problem, not a computer science problem.

so you are telling me that hallucinations (that by definition happen at the model layer) are an engineering problem ? so if we just spin up the right architecture, hallucinations won't be a problem anymore ? I have doubts

Re: The Agent2Agent Protocol (A2A)

#167
post #144

Earlier quoted context omitted.

Morden software consists of separation of responsibilities between services and a higher plane orchestrating the data flow for business logic. If you believe there is value in fuzzy tasks being done by LLMs then from that it follows that having separate "agent" services with a higher order orchestrator would be required. Each calling LLMs on their own inside.

I don't buy it. Why would I want my LLM to talk to some other LLM and introduce even more space for weird, non-deterministic bugs when I could have my LLM call a deterministic API to achieve the same thing?

Isn't an agent just a system prompt + specific tools? Why not just switch out the system prompt and tools in the same context?

Re: The Agent2Agent Protocol (A2A)

#168
post #166

Earlier quoted context omitted.

There's a simple reason for that. AI (real AI) is now an engineering problem, not a computer science problem.

so you are telling me that hallucinations (that by definition happen at the model layer) are an engineering problem ? so if we just spin up the right architecture, hallucinations won't be a problem anymore ? I have doubts

[deleted]

Re: The Agent2Agent Protocol (A2A)

#170
post #154

Earlier quoted context omitted.

the architecture astronauts are back at it again. instead of spending time talking about solutions, the whole AI space is now spending days and weeks talking about fun new architectures. smh https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit

There's a simple reason for that. AI (real AI) is now an engineering problem, not a computer science problem.

And that's how this will end up stagnating into nothing other than fractured enterprise "standards"

There is no evidence that (real AI) is even close to being solved, from a neuroscientific, algorithmic, computer science or engineering perspective. It's far more likely we're going down a dead-end path.

I'm now waiting for the rebrand when the ass falls out of AI investment, the same way it did when ML became passé.

Post reply on HN