Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Agent2Agent Protocol (A2A)

developers.googleblog.com

Post reply on HN
Print view View original

261–270 of 293 posts

Re: The Agent2Agent Protocol (A2A)

#261

Post by tomaskafka »

__loam wrote: post #208
phillipcarter wrote: post #206

Earlier quoted context omitted.

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.

Langchain is one of the most hilarious libraries I've ever had the displeasure of looking through. Many of the abstractions look like they were written by a college student who took clean code way too literally. Many of the methods are so trivial and shallow that I'm shocked people use it in any serious capacity.

This. I was amazed opening something like PagagraphLineReaderFactory, thinking it somehow deals smartly with paragraph boundaries and too long paragraphs etc., and finding a trivial single line regex wrapped in two screens of OOP boilerplate.

Re: The Agent2Agent Protocol (A2A)

#263

Post by mlenhard »

swyx wrote: post #157
mlenhard wrote: post #76

Earlier quoted context omitted.

I was in the same boat in regards to trying to find the actual JSON that was going over the wire. I ended up using Charles to capture all the network requests. I haven't finished the post yet, but if you want to see the actual JSON I have all of the request and responses here https://www.catiemcp.com/blog/mcp-transport-layer/

itd be nice if you prettified your json in the blogpost fwiw i thought the message structure was pretty clear on the docs https://modelcontextprotocol.io/docs/concepts/architecture#m...

Yeah, I plan on improving the formatting and adding a few more examples. There were even still some typos in the piece. To be honest, I didn't plan on sharing it yet; I just figured it might be helpful for the OP, so I shared it early.

I also think the docs are pretty good. There's just something about seeing the actual network requests that helps clarify things for me.

Re: The Agent2Agent Protocol (A2A)

#264

Post by simonw »

IanCal wrote: post #258
simonw wrote: post #190

Earlier quoted context omitted.

Because if a company built an LLM that can perform actions, they almost certainly did that by building an API first for it to use as a tool.

But so much more besides that, including the model itself, RAG, the agentic workflow control, moderation, etc. There's also a huge factor of maintenance, that's a key reason why companies have different internal and external APIs - they don't just open up everything internal and hand the code for managing all of that to you. Interface design is really important. Not to mention the cost being a factor here - who pays…

Offering up an LLM-fronted "agent" for people to send their LLMs to talk to feels a whole lot more expensive and complicated to me than operating a traditional API endpoint.

Re: The Agent2Agent Protocol (A2A)

#265

Post by mindcrime »

rapjr9 wrote: post #251
mindcrime wrote: post #114

Earlier quoted context omitted.

Later renamed as D'Agents[1]. Still never got any serious industry adoption as far as I know, but I guess the code is still out there if somebody wanted to do something with it. [1]: https://wiki.tcl-lang.org/page/D%27Agents+%28formerly+Agent+...

I worked as a programmer for the D'Agents group at Dartmouth. The Tcl agent system was ported to Java and we did a variety of experiments with it, mostly centered around information retrieval. I built a Beowulf cluster which we populated with a distributed database of Usenet news. Agents could jump onto the cluster, do multistep queries, and then jump back with the condensed results. We did some work with the US Navy…

Wow, cool stuff. I never used AgentTCL or D'Agents for anything, but I became aware of both sometime last year and spent a little time reading up on the whole thing. I believe there was a chapter specifically on AgentTCL in one of the books I read.

In some ways, it's a shame it didn't catch on, but the security / access control issues you mention certainly make a lot of sense. That seems to be the big issue that derailed most, if not all, of the various "mobile code" initiatives over the years.

Re: The Agent2Agent Protocol (A2A)

#266

Post by alittletooraph2 »

thebytefairy wrote: post #245
a_wild_dandan wrote: post #161

Earlier quoted context omitted.

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.

Creating new standards is not easy, largely because everyone has to agree that they will use this particular one. Plastering it with endorsements attempts to show that there is consensus and give confidence in adoption. If they didn't put them in, you'd instead say nobody is using or going to use this.

you know how the endorsements work right? some comms intern writes a quote, emails it to someone at the other companies for the go ahead/approval, and that's how you get dozens of companies all spouting BS that kinda sounds the same.

Re: The Agent2Agent Protocol (A2A)

#267

Post by Xelynega »

skeledrew wrote: post #153
Xelynega wrote: post #150

Earlier quoted context omitted.

This just furthers my theory that people pushing for MCP don't understand how networking and protocols work. stdio is a file that your computer can write to and read from HTTP is a protocol typically used over TCP websockets is a protocol initiated via HTTP, which again is typically over TCP Both HTTP and websockets can be done over stdio instead of TCP. It sounds like MCP has a lot more "irrelevant baggage" I need t…

The entire point can be summed in the first 5/6s of that. You don't need to know any of it, because it's irrelevant (at that abstraction). Just as it's irrelevant to know how registers work, to allocate and free memory, avoid/handle segfaults, etc if using a high level language like Python, vs Assembly or C.

That doesn't sound like the case for MCP though. It sounds like when implementing an MCP server there is a difference between the three transport methods that requires different code on the server.

This is a problem solved by other protocols that are just stacked on top of eachother without knowing how eachother work.

Re: The Agent2Agent Protocol (A2A)

#268

Post by IanCal »

simonw wrote: post #264
IanCal wrote: post #258

Earlier quoted context omitted.

But so much more besides that, including the model itself, RAG, the agentic workflow control, moderation, etc. There's also a huge factor of maintenance, that's a key reason why companies have different internal and external APIs - they don't just open up everything internal and hand the code for managing all of that to you. Interface design is really important. Not to mention the cost being a factor here - who pays…

Offering up an LLM-fronted "agent" for people to send their LLMs to talk to feels a whole lot more expensive and complicated to me than operating a traditional API endpoint.

A traditional API endpoint wrapping an agent? That's pretty much what this is but as a standard so we don't need to build thousands of them.

Re: The Agent2Agent Protocol (A2A)

#269

Post by soccernee »

This looks a lot like AGNTCY: https://agntcy.org/

A quick scan of the "partners" for A2A includes many of the same groups that helped launch AGNTCY. Either they jumped ship or they're teaming up with everyone. The Google announcement does read like marketing hype, though, so it remains to be seen how functional it is.

Let the inter-agent standard wars begin.

Re: The Agent2Agent Protocol (A2A)

#270

Post by skeledrew »

Xelynega wrote: post #267
skeledrew wrote: post #153

Earlier quoted context omitted.

The entire point can be summed in the first 5/6s of that. You don't need to know any of it, because it's irrelevant (at that abstraction). Just as it's irrelevant to know how registers work, to allocate and free memory, avoid/handle segfaults, etc if using a high level language like Python, vs Assembly or C.

That doesn't sound like the case for MCP though. It sounds like when implementing an MCP server there is a difference between the three transport methods that requires different code on the server. This is a problem solved by other protocols that are just stacked on top of eachother without knowing how eachother work.

That depends on the library implementation. A given library can be anywhere on the spectrum from "user knowledge and management of the transport methods required" to "transport method is determined by protocol format or invocation" (eg. "local://..." vs "remote://...").
Post reply on HN