Live data from Hacker News

Don't Build Multi-Agents

cognition.ai

51–60 of 95 posts

Re: Don't Build Multi-Agents

#51
> By using React, you embrace building applications with a pattern of reactivity and modularity, which people now accept to be a standard requirement, but this was not always obvious to early web developers.

This is quite a whopper. For one thing, the web started off reactive. It did take a while for a lot of people to figure out how to bring that to client-side rendering in a reasonably decent way (though, I'm sorry, IMO that doesn't actually include react). Second, "modularity" has been a thing for quite some time before the web existed. (If you want to get down to it, separating and organizing and your processes in information systems predate computers.)

Re: Don't Build Multi-Agents

#52

I'm building a simple agent accessible over SMS for a family member. One of their use cases is finding recipes. A problem I ran into was that doing a web search for recipes would pull tons of web pages into the context, effectively clobbering the system prompt that told the agent to format responses in a manner suited for SMS. I solved this by creating a recipe tool that uses a sub-agent to do the web search and retu…

You mean sub-agent as in the formatting agent calls on the the search-and-filter agent? In that case you might just make a pipeline. Use a search agent, then a filter agent (or maybe only one search-and-filter agent), then a formatting agent. Lots of tasks work better with a fixed pipeline than with freely communicating agents.

Re: Don't Build Multi-Agents

#53
post #43

"It is now 2025 and React (and its descendants) dominates the way developers build sites and apps." Is there any research which tells react is dominating or most of the internet is not vanilla HTML but react?

There's two ways to answer this:

1. On one hand, walled gardens like Facebook, Instagram, YouTube, etc, are most of the internet and they decidedly use React (or similar) frameworks. So from that perspective, the statement is sorta trivially true.

2. There may well be a horde of websites that are pure HTML rendering. But, those sites are not largely being developed by developers – they are being generated by platforms (like Squarespace, etc.) so are out of the scope of "sites and apps built by developers"

All this is stated without data, of course.

Re: Don't Build Multi-Agents

#54

There’s both “no multi-agent system” and “multi-agent system,” depending on how you look at it. In reality, you’re always hitting the same /chat/completion API, itself has no awareness of any agents. Any notion of an agent comes purely from the context and instructions you provide. Separating agents, has a clear advantage. For example, suppose you have a coding agent with a set of rules for safely editing code. Then…

There's both "no multi-program system" and "multi-program system", depending on how you look at it. In reality, you're always executing the same machine code, itself has no awareness of programs.

Re: Don't Build Multi-Agents

#55
Don't listen to anyone who tells you how to build an agent. This stuff has never existed before in the history of the world, and literally everyone is just figuring it out as we go. Work from the simplest basic building blocks possible and do what works for your use case. Eventually things will be figured out, and you can worry about "best practices" then. But it's all just conjecture right now.

Re: Don't Build Multi-Agents

#56
post #54

There’s both “no multi-agent system” and “multi-agent system,” depending on how you look at it. In reality, you’re always hitting the same /chat/completion API, itself has no awareness of any agents. Any notion of an agent comes purely from the context and instructions you provide. Separating agents, has a clear advantage. For example, suppose you have a coding agent with a set of rules for safely editing code. Then…

There's both "no multi-program system" and "multi-program system", depending on how you look at it. In reality, you're always executing the same machine code, itself has no awareness of programs.

This unironically helped me work through a bug just now

Re: Don't Build Multi-Agents

#59

We're in the context engineering stone age. You the engineer shouldn't be trying to curate context, you should be building context optimization/curation engines. You shouldn't be passing agents context like messages, they should share a single knowledge store with the parent, and the context optimizer should just optimally pack their context for the task description.

Great insight!

*We're hand-crafting context like medieval scribes when we should be building context compilers.*

Re: Don't Build Multi-Agents

#60
post #8

Is it concerning to anyone else that the "Simple & Reliable" and "Reliable on Longer Tasks" diagrams look kind of like the much maligned waterfall design process?

One reason it is concerning.

I am mostly worried that I am wrong, in my opinion, that "agents" is a bad paradigm for working with LLMs

I have been using LLMs since I got my first Open AI API key, I think "human in the loop" is what makes them special

I have massively increased my fun, and significantly increased my productivity using just the raw chat interface.

It seems to me that building agents to do work that I am responsible for is the opposite of fun and a productivity sink as I correct the rare, but must check for it, bananas mistakes these agents inevitably make

Post reply on HN