Multi-agent orchestration: 30,000 lines, 150k tokens

In September 2026 we finished an MCP upgrade that touched roughly 30,000 lines of code. It ended with about 150,000 tokens in context. The work was split across five subagents running in parallel, each on its own part of the change.

The line count is not the interesting number. The interesting number is the one that stayed small. Thirty thousand lines through a single long-running agent would have buried the session long before the end, and the usual answer to that is to wait for a bigger context window. It is the wrong answer. What fixed it here was a different shape of work, and the shape is three rules you can copy without adopting anyone's framework.

A coding agent degrades well before it runs out of context window. Working with Claude, we have seen quality start to slip around 500,000 tokens of context. That is our own observation rather than a benchmark, and it is where answers begin drifting away from what is in the repository. The practical rule we work to is to stay under roughly half the available window and treat the rest as headroom, not as capacity.

That rule sounds wasteful until you watch what happens past it. The model does not announce the moment it stops tracking a decision made two hours ago. It keeps answering confidently, and the cost lands on whoever reviews the diff. This failure mode now has a name, context rot, and the honest reading is that a long session is not a long memory.

So the budget is fixed, and the work is not. The only lever left is who holds which part of the context.

The setup has three levels, and most of the value sits in the top two.

Layer 0 is a plain chat with a human. It exists to clarify intent, not to write code. The output of that conversation is a tailored prompt for the agent that will do the work. Writing that prompt as a deliberate step keeps the vague half of the thinking out of the working context. The alternative is typing the first version of the task straight into the session that will execute it.

Layer 1 is the orchestrator. It owns the plan and it owns review. It does not write the feature.

Dev subagents and review subagents sit below that. The orchestrator spawns them, each with a narrow task and a context that holds only what that task needs. This is AI agent orchestration in its ordinary sense, with one difference that matters. The subagents are disposable and the orchestrator is not. When a dev subagent finishes, its context goes away. What survives is whatever got written down.

The orchestrator writes a detailed plan in markdown and iterates on it before a single dev subagent starts. This ordering is the whole trick, and it is easy to skip because it feels like delay.

Spawning first is what produces the failure everyone recognises. A dev agent gets a half-specified task, starts coding, hits review feedback, and reacts to it immediately. The word for it is panic. The agent treats every comment as an instruction. You end up reviewing the reaction rather than the work.

A plan that has been iterated on at layer 1 removes most of that, because the dev subagent is not deciding what the task is any more. It is executing a decision that already has a written form.

A dev agent that is handed review feedback sorts it into important and unimportant first. Only then does it change code.

This sounds like a formality and it is not. Review comments arrive as a flat list with no priority. A genuine correctness problem sits next to a naming preference and a suggestion the reviewer was not sure about. A human engineer sorts that list without noticing they are doing it. An agent does not. Without the sorting step it works through the list in order, with equal energy, and the real finding gets the same treatment as the nitpick.

The failure this prevents is the one described above. An agent that reacts to feedback the moment it arrives starts coding before it has decided whether the comment matters.

Every agent in the setup writes its specification, plan and progress to separate files that git does not track. The orchestrator keeps its own progress file.

The reason is recovery. An interrupted session, a context limit you hit, a machine that went to sleep. In a chat-only setup all three mean starting the explanation again. With the state on disk, the next run reads where the work got to and continues. The files also make the work legible to a human mid-flight, which is the part you appreciate when something has gone sideways and you need to know what the agent thought it was doing.

This is not a theory we are proposing. Sofie Meyer, another engineer on the team, confirmed the same thing from her own work. She keeps a separate markdown plan that the agent ticks off as it goes, and it worked well for her in practice. Two people reporting the same file is weak evidence, but it is the kind we trust more than a framework's README.

Splitting work across subagents buys you context, and context is not the only constraint.

It does not make a badly specified task succeed. If layer 0 produced a vague prompt, the orchestrator will write a confident plan for the wrong thing and five subagents will build it in parallel, faster than one agent would have.

It does not remove review. All three rules above are about getting better input to a human reviewer, not about replacing one, and everything we normally run around agentic workflows still applies on top.

It also does not generalise to every task. A 30,000-line change splits cleanly because it has parts. A tangled refactor where every file depends on every other one does not, and forcing it into subagents mostly produces merge conflicts between agents.

If you want one thing out of this, make it rule three. Writing plan and progress to a file is a ten-minute change to how you prompt, it costs nothing when the session goes well, and it saves the whole session when it does not.

Rules one and two are a bigger step, because they mean building something that holds the plan and sorts the feedback. That is a real piece of engineering. But the ordering is what makes the token budget work. Context stays small because each agent only ever holds its own slice. The connective tissue lives in files and in the orchestrator, not in one very long conversation.

The upgrade that started this article was not finished by a smarter model. It was finished by a smaller context, used more carefully. If you are already doing agentic coding day to day and the sessions keep getting longer, that is the lever worth pulling before you go looking for a bigger window.