The monolith agent problem

1 min read
On trails:AGPATstep 1/6

A monolith agent, or super agent, owns every task, every tool and every instruction in one place. It is fine for a demo and becomes problematic as the job grows, for the same reasons a software monolith does.

Three ways it breaks

  • Prompt complexity. Every new duty adds rules to the one prompt, and the rules start to collide. Managing the prompt turns into the real work.
  • Context window limit. The prompt, every tool schema and the running history all compete for one finite window (see context engineeringContext engineeringDeciding what the model sees on every call, because the window is finite.Opens in a new tab).
  • Single point of failure. One confused step takes the whole agent down, and nothing else exists to catch it.
One super agent holds one huge prompt, every tool and one context window. Splitting it gives a router and three specialist agents, each with its own prompt and tools. Super agent one huge prompt every tool one context window one point of failure split Router manages only Specialist 1 own prompt, tools Specialist 2 own prompt, tools Specialist 3 own prompt, tools
The way out: specialised agents instead of a monolith.

What splitting gives

The fix is specialised agents instead of one monolith, each with a small prompt, its own tools and its own context. Two things come with it. Parallelisation: independent specialists can run at the same time (see swarm and map-reduceSwarm and map-reduceA queen agent spawns a worker per task, then collects the results.Opens in a new tab). Debate: one agent can critique another’s work, the multi-agent form of reflectionReflectionCritique the output before finalizing it: one agent does, another reflects.Opens in a new tab (see group chatGroup chat patternAgents that talk to each other in one thread, with a manager keeping order.Opens in a new tab).

LangChain’s docs name the same reasons: context management, parallelisation, and letting separate teams own separate pieces.

The catch

Anthropic’s research system, a lead agent with subagents, beat a single agent by 90.2% on their internal research evaluation. It also used about 15× the tokens of a chat. They add that multi-agent fits badly when agents must share the same context or depend heavily on each other.

So split when the monolith hurts, not before. The next notes are four ways to split: routerRouter patternA manager that only decides which specialist handles the request.Opens in a new tab, handoffHandoff patternAgents in a fixed sequence, each passing its output to the next.Opens in a new tab, group chatGroup chat patternAgents that talk to each other in one thread, with a manager keeping order.Opens in a new tab and swarmSwarm and map-reduceA queen agent spawns a worker per task, then collects the results.Opens in a new tab.

Sources