Don't Build Multi-Agents
cognition.ai
Don't Build Multi-Agents
1–10 of 95 posts
Re: Don't Build Multi-Agents
#2How 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.
If someone asked me why I think there's an AI bubble, I'd point exactly to this situation.
Re: Don't Build Multi-Agents
#3In 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 substantially different from dynamic context compression/filtering.
I think the only sensible framework is to think in terms of tools, with clear interfaces, and a single "agent" (single linear interaction chain) using those tools towards a goal. Such tools could be LLM-based or not. Forcing a distinction between a "function tool" and an "agent that does somethng" doesn't make sense.
Re: Don't Build Multi-Agents
#4How 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 blame managers that get all giddy about reducing head count. Sure this year, you get a -1% on developer time (seniors believe they get a 20% increase when its really a decrease for using AI)
But then next year and the year after, the technical debt will be to the point where they just need to throw out the code and start fresh.
Then the head count must go up. Typical short term gains for long term losses/bankruptcy
Re: Don't Build Multi-Agents
#5How 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…
Software engineering in general is pretty famous for unironically being disdainful of anything old while simultaneously reinventing the past. This new wave is nothing new in that regard.
I'm not sure that means the people who do this aren't good engineers, though. If someone rediscovers something in practice rather than through learning theory, does that make them bad at something, or simply inexperienced? I think it's one of the strengths of the profession that there isn't a singular path to reach the height of the field.
Re: Don't Build Multi-Agents
#6In 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.
Re: Don't Build Multi-Agents
#7[deleted]
Re: Don't Build Multi-Agents
#8Is 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?
Re: Don't Build Multi-Agents
#9Is 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?
It looks more like alchemy, thb.
Re: Don't Build Multi-Agents
#10I'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 return the most promising recipe to the main agent. When the main agent uses this tool instead of performing the web search itself, it is successfully able to follow the system prompt's directions to format and trim the recipe for SMS. Using this sub-agent to prevent information from entering the context dramatically improved the quality of responses. More context is not always better!
I bring this up because this article discusses context management mostly in terms of context windows having a maximum size. I think that context management is far more than that. I'm still new to this building agents thing, but my experience suggests that context problems start cropping up well before the context window fills up.