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

71–80 of 95 posts

Re: Don't Build Multi-Agents

#71

Post by pglevy »

CuriouslyC wrote: post #26

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.

Not an engineer but I think this is where my mind was going after reading the post. Seems like what will be useful is continuously generated "decision documentation." So the system has access to what has come before in a dynamic way. (Like some mix of RAG with knowledge graph + MCP?) Maybe even pre-outlining "decisions to be made," so if an agent is checking in, it could see there is something that needs to be figured out but hasn't been done yet.

Re: Don't Build Multi-Agents

#73

Post by CuriouslyC »

pglevy wrote: post #71
CuriouslyC wrote: post #26

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.

Not an engineer but I think this is where my mind was going after reading the post. Seems like what will be useful is continuously generated "decision documentation." So the system has access to what has come before in a dynamic way. (Like some mix of RAG with knowledge graph + MCP?) Maybe even pre-outlining "decisions to be made," so if an agent is checking in, it could see there is something that needs to be figure…

I actually have a "LLM as a judge" loop on all my codebases. I have an architecture panel that debates improvements given an optimization metric and convergence criteria and I feed their findings into a deterministic spec generator (cue /w validation) that can emit unit/e2e tests, scaffold terraform. It's pretty magical.

This cue spec gets decomposed into individual tasks by an orchestrator that does research per ticket and bundles it.

Re: Don't Build Multi-Agents

#74

Post by faangguyindia »

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.

History is nothing just list of dict containing role and messages? You can evict any entry at any point.

Re: Don't Build Multi-Agents

#75

Post by adastra22 »

kordlessagain wrote: post #62
clbrmbr wrote: post #44

Earlier quoted context omitted.

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!

Isn’t it easier to just write scripts to launch clause in different worktrees?

Re: Don't Build Multi-Agents

#76

Post by adastra22 »

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.

What is the use case?

Re: Don't Build Multi-Agents

#77

Post by adastra22 »

datadrivenangel wrote: post #49
faangguyindia wrote: post #34

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…

Calling a different prompt template an 'agent' doesn't help communicate meaningful details about an overall system design. Unnecessary verbiage or abstraction in this case.

It is what it is. That ship has sailed.

Re: Don't Build Multi-Agents

#78

Post by adastra22 »

CuriouslyC wrote: post #73
pglevy wrote: post #71

Earlier quoted context omitted.

Not an engineer but I think this is where my mind was going after reading the post. Seems like what will be useful is continuously generated "decision documentation." So the system has access to what has come before in a dynamic way. (Like some mix of RAG with knowledge graph + MCP?) Maybe even pre-outlining "decisions to be made," so if an agent is checking in, it could see there is something that needs to be figure…

I actually have a "LLM as a judge" loop on all my codebases. I have an architecture panel that debates improvements given an optimization metric and convergence criteria and I feed their findings into a deterministic spec generator (cue /w validation) that can emit unit/e2e tests, scaffold terraform. It's pretty magical. This cue spec gets decomposed into individual tasks by an orchestrator that does research per tic…

I think we are all building the same thing. If only there was an open source framework for aggregating all our work together.

Re: Don't Build Multi-Agents

#79

Post by adastra22 »

hansvm wrote: post #39
CuriouslyC wrote: post #26

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.

You're not wrong. This is just a storage/retrieval problem. But ... the current systems have limits. If you want commercial success in <3yrs, are any of those ideas remotely viable?

Dude, ChatGPT isn’t even 3 years old. That’s an eternity.

Re: Don't Build Multi-Agents

#80

Post by adastra22 »

worik wrote: post #60
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?

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 a…

The thing is, the same agent that made the bananas mistake is also quite good at catching that mistake (if called again with fresh context). This results in convergence on working, non-bananas solutions.
Post reply on HN