Hacker News Reader

Comment by simonw | Hacker News Reader

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!

View on HN

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

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 when they cannot be modeled as tools.

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?

No.

You have anything else that modifies the context, tools, model, and most importantly perhaps the iteration that controls what's going on with those other values.

Why do you assume there's a deterministic API doing the same thing?

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 for which part.

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.

Because there often is?

Reply on news.ycombinator.com