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

11–20 of 95 posts

Re: Don't Build Multi-Agents

#11

Post by adastra22 »

> 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 simultaneously is inadvisable for obvious reasons, at least without workspace separation).

Re: Don't Build Multi-Agents

#13

Post by jll29 »

behnamoh wrote: post #2

How is this fundamentally any different than Erlang/Elixir concepts of supervisors controlling their child processes? It seems like the AI industry keeps re-discovering several basic techniques that have been around since the 80s. I'm not surprised—most AI "engineers" are not really good software engineers; they're often "vibe engineers" who don't read academic papers on the subject and keep re-inventing the wheel. I…

yes, people re-discover stuff, mostly beacause no-one reads older papers. I also thought of Erlang and OAA.

In the early 2000s, we used Open Agent Architecture (OAA) [1], which had a beautiful (declarative) Prolog-like notation for writing goals, and the framework would pick & combine the right agents (all written in different languages, but implementing the OAA interface through proxy libraries) to achieve the specified goals.

This was all on boxes within the same LAN, but conceptually, this could have been generalized.

[1] https://medium.com/dish/75-years-of-innovation-open-agent-ar...

Re: Don't Build Multi-Agents

#14

Post by DarkNova6 »

mreid wrote: 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?

To me it seems more like the typical trap of a misfit bounded context.

Re: Don't Build Multi-Agents

#15

Post by ramchip »

behnamoh wrote: post #2

How is this fundamentally any different than Erlang/Elixir concepts of supervisors controlling their child processes? It seems like the AI industry keeps re-discovering several basic techniques that have been around since the 80s. I'm not surprised—most AI "engineers" are not really good software engineers; they're often "vibe engineers" who don't read academic papers on the subject and keep re-inventing the wheel. I…

I've done a lot of Erlang and I don't see the relation? Supervisors are an error isolation tool, they don't perform the work, break it down, combine results, or act as a communication channel. It's kind of the point that supervisors don't do much so they can be trusted to be reliable.

Re: Don't Build Multi-Agents

#16

Post by adastra22 »

jskalc92 wrote: post #6
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…

I think the most common implementation of "subagents" doesn't get full context of a conversation, rather just an AI-generated command. Here task is fullfilled with the full context so far, and then compressed. Might work better IMO.

In my experience it does not work better. There are two context related values to subagent tool calls: (1) the subagent trials and deliberations don’t poison the callers context [this is a win here]; and (2) the called agent isn’t unduly influenced by the caller’s context. [problem!]

The latter is really helpful for getting a coding assistant to settle on a high quality solution. You want critic subagents to give fresh and unbiased feedback, and not be influenced by arbitrary decisions made so far. This is a good thing, but inheriting context destroys it.

Re: Don't Build Multi-Agents

#17

Post by edoceo »

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…

Are you in USA? How to get around those 10DLC limits on typical SMS/API things (eg Twilio). Or did you go through that process (which seems a lot for a private use-case)

Re: Don't Build Multi-Agents

#19

Post by WalterSear »

behnamoh wrote: post #2

How is this fundamentally any different than Erlang/Elixir concepts of supervisors controlling their child processes? It seems like the AI industry keeps re-discovering several basic techniques that have been around since the 80s. I'm not surprised—most AI "engineers" are not really good software engineers; they're often "vibe engineers" who don't read academic papers on the subject and keep re-inventing the wheel. I…

Apart from requiring entirely the opposite solution?

With respect, if there's an AI bubble, I can't see it for all the sour grapes, every time it's brought up, anywhere.

Re: Don't Build Multi-Agents

#20

Post by wewtyflakes »

This resonates heavily with our experience. We ended up using one agent + actively managed context, with the smartness baked into how we manage that context for that one agent, rather than attempting to manage expectations/context across a team of agents.
Post reply on HN