An agent that can do everything — and fails for exactly that reason
The first time you build an AI agent, the instinct is always the same: you make it more capable. One more tool, so it can write files too. One more section in the system prompt to catch last week's edge case. One more line of instructions because it slipped up on some corner case. The agent grows bigger, cleverer, more universal — and for a while that works remarkably well.
Then it tips over. Past a certain point, more doesn't make the agent better; it makes it worse. It loses the thread of what it was actually meant to do halfway through. It reaches for the wrong one of its thirty tools. It goes round in loops, runs the same search three times, contradicts itself between two steps. The obvious reflex is to pile on more instructions — and that makes the problem worse rather than better.
The answer is not a cleverer single agent. It is a system of several. Not because many agents are intrinsically better than one — they aren't, more on that below — but because a single context and a single prompt have a real, physical ceiling. Understand that ceiling and you understand why orchestration isn't a buzzword but an architectural decision.
Why a single agent hits a ceiling
The ceiling has three causes, and all three live in the context window — the working memory in which the agent carries its entire task, its tools, and its history so far.
First: the context window fills up with ballast. Every tool an agent knows about costs space — not just when it's called, but permanently. The full definition of each tool, with its parameters, descriptions and examples, sits in the context at every single reasoning step, whether the tool is needed right then or not. An agent with five tools carries a lean toolbox. An agent with thirty carries an entire hardware shop around with it, and in nine steps out of ten, twenty-nine of those tools are irrelevant. That ballast competes with the actual task for attention — and at every step the model has to fish the one right option out of thirty plausible ones. The error rate climbs precisely where the choice is widest.
Second: reasoning degrades as history grows. A model doesn't reason equally well over a context of 5,000 tokens as over one of 150,000. The longer the history — every earlier tool call, every intermediate output, every failed attempt — the more noise sits between the current question and the information that answers it. The model loses sight of early instructions, overwrites its own conclusions, tangles itself in contradictions between step three and step seventeen. There's an apt name that has caught on for this: "context rot" — the slow decay of answer quality as the context grows fuller and murkier.
Third: one prompt tries to be everything. A jack-of-all-trades agent needs a system prompt that can research and write code and query databases and negotiate with the user. Each of those roles pulls the prompt in a different direction. The instructions for careful research sit next to the ones for cautious writing, and the model has to decide for itself, moment by moment, which hat is on. The result is a prompt that does everything half-well and nothing fully — the generalist that's passable everywhere and excellent nowhere.
These three effects compound one another. More tools means more context, means faster rot, means worse decisions, means more failed attempts, means yet more context. You cannot prompt your way out of this loop. You have to cut it apart.
Patterns that work
The way out is always the same basic idea: split the task, and give each part its own fresh, narrow context. How you do that in practice follows a handful of proven patterns.
Orchestrator and worker. A central agent — the orchestrator — keeps track of the goal and the strategy but does barely any detailed work itself. It breaks the task down and delegates the pieces to worker agents, each of which gets exactly one brief, does it in its own context, and reports back only the result. The orchestrator never sees the 40,000 tokens the worker generated while searching through twelve files — it gets the three sentences of conclusion. This is exactly how Claude Code's sub-agents work: via the Task tool, the main agent spins up a sub-agent that carries out a bounded piece of research in an isolated context and returns only the essence. The main context stays clean, no matter how much the sub-agent had to rummage.
Planner, executor, checker. Rather than letting one agent plan and act and verify, you separate the three phases into three roles. A planner agent works out what to do and writes an explicit plan. An executor agent takes that plan and carries it out step by step, without constantly renegotiating the strategy. A checker agent takes the result and asks: is this right? The advantage isn't only a clean context but that each role embodies a different mode of thinking — divergent when planning, focused when executing, sceptical when checking. A single agent would have to switch between those modes in the same frame of mind, and that rarely comes off.
Specialists with a narrow tool set. An agent that only queries the database needs three tools, not thirty. Its prompt can devote itself entirely to handling SQL cleanly. An agent that only reviews pull requests needs no deployment tool. The narrower the role, the shorter the prompt, the smaller the toolbox, the more accurate the selection. You trade versatility for reliability — and for most sub-tasks, that's a good trade.
Isolated sub-contexts as map-reduce. Perhaps the strongest pattern: when a task runs across a large set of similar things — search this codebase, review these two hundred documents, analyse these fifty endpoints — you spread it across many parallel sub-agents, each of which handles one slice and returns only its conclusion. No single context ever sees the whole codebase; it sees only the distilled findings. This is exactly the pattern Anthropic describes in its write-ups of its multi-agent research system: a lead agent breaks down an open-ended research question and spins up several sub-agents that pursue different strands in parallel. Each sub-agent has its own context window and compresses its findings before returning them. The lead agent synthesises the answer from those compressions — and never had to hold the raw mass of every searched source in its head at once.
Every one of these patterns shares one principle: context isolation is the actual product. It isn't the number of agents that makes the system better, but that each agent sees only what it needs for its narrow job.
The hand-off problem
The moment you spread work across several agents, a new problem appears that never existed with a single agent: the hand-off. What exactly does one agent pass to the next — and in what form?
The comfortable but dangerous route is free text. Agent A writes up in prose what it found, agent B reads it and carries on. That works in simple cases and fails at precisely the moment it matters. Because free text is ambiguous. When agent A writes "the payment succeeded, apart from one case", agent B has to guess which case, whether it's relevant, what "succeeded" means here. Across several hand-offs, that ambiguity turns into a game of telephone: each agent reinterprets the slightly fuzzy output of the previous one a little, and after four stops the last agent is working on a task only distantly related to the original. Nobody lied; everyone merely nudged the meaning. The result is wrong all the same.
The countermeasure is unspectacular and effective: structured outputs instead of free text. You define a schema — which fields a hand-off must contain, in what format, with which permitted values — and force every agent to deliver its results in exactly that shape. Instead of "the payment mostly succeeded", the agent returns { "status": "partial", "succeeded": 199, "failed": 1, "error_id": "txn_88231" }. The next agent has nothing to interpret; it reads fields. A schema also enforces completeness: if a required field is missing, it shows up immediately instead of eating its way through the chain as a silent gap. The hand-off goes from a narrative to a contract — and contracts are the sort of thing you can build a system on.
Verification as its own agent
There's a role almost every serious multi-agent system needs and yet often forgets: the checker. Not as a courtesy, but as a standalone, adversarial agent whose only job is to disprove the others' work.
The reason is structural. An agent that has produced a solution is the worst possible checker of that solution — it shares every assumption that led it into the mistake, and it's conditioned to regard its own output as plausible. Ask that same agent to "double-check that" and it will mostly nod its own work through. A separate checker agent with an opposing brief — "find the fault, assume there is one here" — comes at it with a different disposition. It hunts for the empty list, the unhandled error path, the assumption that doesn't hold. It gets the task and the result and is licensed to doubt both.
That's no guarantee — an AI checker shares some blind spots with the AI producer, and two green ticks aren't twice as safe as one. But an agent with an adversarial brief and a fresh context catches a whole class of faults the producer structurally cannot see. Splitting producing and checking into two roles is one of the cheapest quality gains a multi-agent design has to offer.
The other side: multi-agent isn't free
Now the honest reckoning, because without it you'll push the lesson far too far. Multi-agent systems break the single agent's ceiling — but they don't do it for nothing, and in many cases the price is higher than the gain.
Token costs multiply. Each agent has its own system prompt, its own tool list, its own history — and all of that gets processed afresh at every step. In Anthropic's own measurements, an agent run burns through roughly four times the tokens of a normal chat interaction, and a multi-agent system roughly fifteen times. What costs £2 as a chat request quickly costs £30 as an orchestrated multi-agent run. For tasks with real value, that's well spent. For a simple reformat, it's money on the fire.
Coordination costs overhead — and goes wrong. Agents meant to cooperate get tangled in ways a single agent simply can't. Two workers tackle the same sub-task because the orchestrator handed it out twice. An agent waits on a result that never arrives. Two agents fall into a loop where each reacts to the other's correction. These failure modes only arise from the distribution — the single agent just doesn't have them.
Latency and debugging get worse. A multi-agent run is as slow as its slowest chain, and when something wrong comes out at the end, tracing the cause is far harder: was it the planner, a worker, the hand-off in between? Non-determinism sharpens all of this — the same input leads, across several probabilistic agents, to different runs, and a fault that shows up only on every fifth run is hell to reproduce.
The sober upshot: "more agents" is not "better". Most tasks are done faster, cheaper and more reliably by a single, well-tailored agent. Multi-agent pays off only when the task genuinely decomposes and the sub-tasks are independent — parallel research across many sources, map-reduce over a large codebase, cleanly separated phases with clean hand-offs in between. If a task doesn't split up sensibly, every extra agent only adds coordination cost without lifting the ceiling that's actually the constraint. The skill isn't building as many agents as possible, but recognising when one is the right answer.
Conclusion
The reflex to keep making an agent more capable is understandable and, up to a point, correct. Beyond that point it reverses: more tools, more instructions, more context make the agent not cleverer but more scattered. The single agent's ceiling isn't a question of better prompts but a structural limit — and you don't overcome it with a more ingenious prompt, but with a thought-through system: specialist agents with narrow roles, isolated contexts, structured hand-offs, a checker of its own.
But building such a system is a design task, not a magic formula. Run multi-agent for its own sake and you buy yourself token costs, latency and non-determinism without the gain to show for it. The hard, valuable work isn't in building many agents but in deciding where the decomposition genuinely holds and where a single agent is the more honest answer.
This is exactly where our standard at NH Labs lies. We build agent systems in which every agent has a narrow, clearly bounded job — and in which a human owns the orchestration design: they decide what gets decomposed and what doesn't, what the hand-offs look like, and where a checker is needed. Not as many agents as possible, but the right ones, cleanly wired together. That's why our systems work not because they are complex, but because every part of them is simple enough to be reliable.