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

Don't Build Multi-Agents

cognition.ai

Post reply on HN
Print view View original

61–70 of 95 posts

Re: Don't Build Multi-Agents

#61

Post by worik »

sputknick wrote: post #24

This is very similar to the conclusion I have been coming to over the past 6 months. Agents are like really unreliable employees, that you have to supervise, and correct so often that its a waste of time to delegate to them. The approach I'm trying to develop for myself is much more human centric. For now I just directly supervise all actions done by an AI, but I would like to move to something like this: https://git…

> Agents are like really unreliable employees,

Yes

But employees (should) get better over time, they learn from me

Re: Don't Build Multi-Agents

#62

Post by kordlessagain »

clbrmbr wrote: post #44
adastra22 wrote: post #11

> As of June 2025, Claude Code is an example of an agent that spawns subtasks. However, it never does work in parallel with the subtask agent, and the subtask agent is usually only tasked with answering a question, not writing any code. Has this changed since June? Because I’ve been experimenting over the last month with Claude Cide subagents that work in parallel and agents which write code (doing both simultaneousl…

I’ve been quite successful since June doing parallel edits just on different components within the same codebase. But I’ve not been able to do it with “auto-accept” because I need a way to course correct if one of the agents goes off the rails.

I wrote something that watches the directories and started working on a node graph to visualize relationships between changes and dates things like that: https://github.com/kordless/gnosis-flow. It that is useful to you let me know!

Re: Don't Build Multi-Agents

#63

Post by skybrian »

Restricting output from a subagent (not allowing arbitrary strings anywhere in the output) seems like a way to minimize the risks of prompt injection attacks, though? Sometimes you only need to get a boolean or an enum back from a query.

Re: Don't Build Multi-Agents

#64

Post by pbd »

The 'dilution effect' is real - even with plenty of context space left, agents start losing track of their original goals around the 50k token mark. It's not just about fitting information in, it's about maintaining coherent reasoning chains. Single agents with good prompt engineering often outperform elaborate multi-agent orchestrations.

Re: Don't Build Multi-Agents

#65

Post by tfirst »

colonCapitalDee wrote: post #10

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…

The article addresses this specific use under the 'Claude Code Subagents' section.

> The benefit of having a subagent in this case is that all the subagent’s investigative work does not need to remain in the history of the main agent, allowing for longer traces before running out of context.

Re: Don't Build Multi-Agents

#66

Post by [deleted] »

tfirst wrote: post #65
colonCapitalDee wrote: post #10

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…

The article addresses this specific use under the 'Claude Code Subagents' section. > The benefit of having a subagent in this case is that all the subagent’s investigative work does not need to remain in the history of the main agent, allowing for longer traces before running out of context.

[deleted]

Re: Don't Build Multi-Agents

#67

Post by jauntywundrkind »

tfirst wrote: post #65
colonCapitalDee wrote: post #10

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…

The article addresses this specific use under the 'Claude Code Subagents' section. > The benefit of having a subagent in this case is that all the subagent’s investigative work does not need to remain in the history of the main agent, allowing for longer traces before running out of context.

This very narrow very specific single-purpose task-oriented subagent was one of the first things talked about in this every lovely recent & popular submission (along with other fun to read points):

What makes Claude Code so damn good (and how to recreate that magic in your agent)!? https://minusx.ai/blog/decoding-claude-code/ https://news.ycombinator.com/item?id=44998295

Re: Don't Build Multi-Agents

#68

Post by OutOfHere »

peab wrote: post #27
curl-up wrote: post #3

In the context compression approach, why aren't the agents labeled as subagents instead? The compressed context is basically a "subtask". This is my main issue with all these agentic frameworks - they always conviniently forget that there is nothing "individual" about the thing they label "an agent" and draw a box around. Such "on demand" agents, spawned directly from previos LLM output, are never in any way substant…

Yeah, i agree with thinking of things as a single agent + tools. From the perspective of the agent, whether the tools are deterministic functions, or agents themselves, is irrelevant.

I think one can simplify it further. There is no agent; it's just tools all the way.

The caveat is that multiple tools must be able to run asynchronously.

Context compression of one's own lengthy context is also useful and necessary as the message chain starts to get too large.

Re: Don't Build Multi-Agents

#69

Post by sitkack »

colonCapitalDee wrote: post #10

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…

The large models have all the recipes memorized, you don't need to do a search.

Re: Don't Build Multi-Agents

#70

Post by OutOfHere »

ramesh31 wrote: post #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.

I would go further and consider that an agent is an unnecessary concept. "Asynchronous tool calling, with context compression" is more on point for solving complex problems.
Post reply on HN