“More agents” is one of the most seductive and most wrong instincts in LLM system design. I know because I shipped a 13-agent architecture for Kubernetes — and then got better results by tearing most of it out.
The maximalist version
The first architecture was capability-maximal: a supervisor LLM routing every turn to one of thirteen specialized agents — logs, metrics, RBAC, lifecycle, deletion, code generation, and more — plus runtime tool synthesis and a four-tier memory system. It worked, and it was the version that got peer-reviewed. But it was big: tens of thousands of lines, a lot of routing logic, and a lot of tokens spent just deciding which agent should handle a request.
The lean version won
A later redesign collapsed the thirteen agents into a single coordinator running a tool-use loop over a small set of guarded tools, with a focused fan-out only for root-cause analysis (gather logs, metrics, and events in parallel). In our cross-version evaluation the lean and platform designs reached higher diagnostic quality at roughly half the token cost of the maximalist version, with a fraction of the code.
Why the reversal?
- Routing is not free. Every hop between agents is tokens spent and a chance to route wrong. Thirteen options is thirteen ways to send a request to the agent that can’t quite handle it.
- Context fragmentation. Splitting a problem across many agents means each sees only a slice. A single coordinator holding the whole picture reasons better about a messy, cross-cutting failure.
- Surface area is cost. More agents means more prompts to maintain, more failure modes, and more tokens — all of which scale against you.
Where multiple agents genuinely help
The nuance: parallel evidence gathering is a real win. Fanning out to pull logs, metrics, and events at the same time, then synthesizing them, is faster and cleaner than doing it serially. That’s specialization for parallelism and clear boundaries — not specialization for its own sake. The lean design kept exactly that fan-out and dropped the rest.
The takeaway
Count agents the way you count microservices: each one should earn its place. If an agent isn’t buying you parallelism, a hard capability boundary, or genuinely independent work, it’s buying you latency, tokens, and bugs. Start with one good reasoner and add structure only where the evidence says it pays.
The peer-reviewed architecture and evaluation are on the research page; the cross-version study is ongoing.