Subagents & Multi-Agent Orchestration

A single AI agent is remarkably capable, but it has one body and one desk. Everything it's working on has to fit inside its single context window, and it does its tasks one after another. Hand it a job that's genuinely wide — "audit every file in this repo for hardcoded secrets" — and you feel the limits: the relevant material won't all fit at once, and reading it serially is slow. The fix is to stop thinking of one agent and start thinking of a team.

Multi-agent orchestration introduces a lead agent — the orchestrator — whose job is not to do the work itself but to divide and delegate. It breaks the task into independent pieces and spins up a subagent for each one. The subagents run in parallel, each tackling its slice at the same time. When they finish, the orchestrator collects their findings and synthesizes them into a single result for you. It's the manager-and-team pattern, applied to AI.

The quietly important detail is that each subagent gets its own fresh context window. A subagent searching the billing module isn't carrying around everything the auth-module subagent read. That isolation is what makes the approach scale: instead of one window straining to hold the whole repo, you have many windows each holding just one focused chunk. The orchestrator only needs the summaries the subagents send back, not their raw working memory.

The shape is always the same. The orchestrator fans out, launching one subagent per piece with a clear, self-contained brief: what to look at, what to produce, and what not to touch. Then it fans in, reading every subagent's report and merging them. Finally it verifies the merged result — running the tests, or handing it to a separate reviewer subagent that has no shared context to bias it.

The timing follows from that shape. The subagents' work overlaps, so it costs only as long as the slowest piece. The split, the merge and the check don't overlap with anything, so they add up. Four 10-minute pieces don't finish in 10 minutes; they finish in the split, plus 10, plus the merge and the check.

Step through one job below. You'll predict when it finishes before you see it. Then flip the pieces to overlapping — the same four modules, but every change also edits one shared file — and watch what happens at the merge.

Parallel agents can't see each other's work. Each one starts from the same snapshot of the code and edits its own copy. That's harmless when the pieces live in different places — four modules, four folders, four findings lists. It breaks down the moment two pieces touch the same file: a shared routes table, a config file, a types file everyone imports. The first edit to land changes the file; every other edit was made against the old version and no longer fits. Something has to be redone, and the redo can't run in parallel either, or it would clash again.

So before fanning out, look for the seams. Good splits follow boundaries the code already has: one module, one service, one directory or one question each. If every piece needs a small change to a shared file, pull that change out — have the orchestrator make it first, or last, by itself — so the parallel pieces really are independent.

Orchestration isn't free, and treating it as a default is a mistake. Every subagent burns its own tokens: each one re-reads the brief, the conventions and whatever shared code it needs before it does anything useful. So four subagents don't cost a quarter each — together they usually cost more than one agent doing the same job, and in the example above (illustrative numbers) the clean split used about 1.35× the tokens to finish more than twice as fast. There's coordination overhead too: the orchestrator has to write clear sub-tasks, wait on the slowest subagent, and stitch together results that might disagree. For a small, linear task — fix one function, rename one variable — all of that is pure waste, and a single agent is faster and cheaper.

So the rule of thumb is simple: reach for multiple agents when the task is wide and splits cleanly, or when it needs an independent check, and stick with one agent when it's narrow, sequential, or tangled through shared files. Used well, orchestration buys you breadth and a second, unbiased opinion — which is exactly what you want when you move on to verifying AI output.