𝗬𝗼𝘂 𝗗𝗼𝗻'𝘁 𝗡𝗲𝗲𝗱 𝗦𝘂𝗯-𝗔𝗴𝗲𝗻𝘁𝘀
Most people draw agent architectures like organizational charts.
They put an Orchestrator at the top. They draw lines to a Researcher, a Coder, and a Tester. It looks clean. It looks professional.
It is a mistake.
In 1975, Fred Brooks wrote that adding more people to a late software project makes it later. This happens because communication costs grow faster than the work gets done.
When you build a swarm of agents, you repeat this mistake.
The orchestrator spends all its time managing subtasks. This creates massive overhead. You are not building an architecture. You are building plumbing.
Here is why sub-agents fail:
- Context loss: A sub-agent runs in its own window. It cannot pass its full reasoning to the parent. It only sends a summary.
- Expensive workarounds: People force agents to write to files or git just so the parent can read what happened. You are reinventing shared memory but making it slower.
- Token waste: You pay to pass context across every boundary. A swarm of N agents costs N+1 in tokens.
- Conflicting decisions: Parallel agents make different assumptions. If two agents build the same thing, they often use different styles or logic.
Research shows that multi-agent frameworks have failure rates between 41% and 87%. These failures happen because agents talk past each other. A better model will not fix this. It is a coordination problem, not a model problem.
How should you build instead?
Follow these two rules:
- If tasks are independent, run them as separate loops. Use two separate programs. This is parallel processing, not a multi-agent system.
- If the task requires a single train of thought, use one single loop.
A single loop keeps all context in one place. It self-corrects easily. It leaves a clean history instead of a messy group chat.
Stop building meshes. Start building loops.
Source: https://dev.to/tony__vi/you-dont-need-sub-agents-1eh7
Optional learning community: https://t.me/GyaanSetuAi