Comment by refactor_master
10 hours ago
So this shows that people who appoint 50-agent "code factory studios" with Bob as the CEO, Alice as the CTO, ... is just a waste of tokens, compared to just asking one agent to write it all? It looks like your agents would internally just re-invent office politics, with 10 subagents writing to /tmp/chatter.md why it's unfair that Bob gets to lead.
I also never understood this desire to build an agent org chart with persistent identities, often giving them names. Paperclip seems to advertise that model. I think it's much simpler and more flexible to simply spawn an agent for each task.
One argument for the persistent identity model is that you can give them special skills and context. I don't believe that's a good argument. In my experience, you can just give each agent access to the full set of tools (including RAG search) in the form of documentation and skills, and they'll use that efficiently. Skills have a tiny front matter and hardly bloat the context, and the documentation just needs to be tree-structured with cross-links for progressive disclosure. LLMs navigate that efficiently, so the cost of having all context accessible is low, while the risk of cutting the context boundaries for the persistent identities non-optimal for a given task is rather high IMO.
I think it is because it is easier for humans to understand what's happening.
Efficiency wise I'd imagine at least picking a leader from the start just saves initial hustle and context window
If agents are differentiated solely by system instructions (persona and focus) while sharing identical models / similar model capabilities and contexts, I agree the architectural value is minimal.
However, a multi-agent system (MAS) utilizing true separation of concerns, where each agent is equipped with highly scoped tool access, isolated knowledge bases (RAG), and defined operational constraints, significantly optimizes accuracy, latency, and token consumption.
In the referenced example, the agents share identical capabilities, toolsets, and context windows. As a result, there is no functional role differentiation, rendering the multi-agent architecture redundant.
it seems to me that would only be true if the amount of knowledge needed to complete a task far exceeds the context limit. Why would that be the case? I find most people are using horribly inefficient contexts, and a naive approach to dark factories/software eng swarms seems to only compound this
> significantly optimizes accuracy, latency, and token consumption.
On what basis do you come to this conclusion with certainty?
Anyone who has used local LLMs will come to this conclusion.
Too much context confuses the LLM. Reduce unnecessary context and performance improves. Not to mention, too much context and you just run out of vram.
Such limitations may be mitigated in future architectures, but it certainly isn't something you can ignore currently.
1 reply →
[dead]
If you leave agents to figure it out, they will spend time figuring it out. If you give agents run-books and roles, they will align with the role at once.
See Conways law for how to mitigate this
Are you making a subtle reference to the Bobiverse series?