4 of 5 · A working choice
Orchestration and subagents
Split work when one context is too crowded, too slow, or too easy to trust without a second check.
- You split
- Independent parts of a larger job
- You gain
- Time, free context, or an independent check
- You spend
- More total tokens and coordination
A long task fills a model's context with files, search results, test logs, and dead ends. The useful conclusions compete with all that raw material for space. When the context window fills up, the model has less room to reason, and the harness may replace old material with a summary that drops detail.
A subagent starts with a fresh context and one scoped job. The agent that hands out the jobs, the orchestrator, gets back a short result instead of every file and failed search that the worker read.
One agent or four workers
Figure 1 runs the same four jobs both ways. On the left, one agent does them one after another, and everything it reads stays in its context. On the right, four workers run at the same time. Each worker fills its own context, sends back a short result, and then discards its context. A verifier checks each result before the orchestrator uses it.
Compare the two stacks, the two clocks, and the two token counters. Find the result that the verifier rejects.
- One agent · time
- 14.7 min
- Orchestrated · time
- 5.1 min
- One agent · tokens
- 192k
- Orchestrated · tokens
- 452k
The figure shows the trade:
- Time. Parallel workers finish when the slowest one finishes. One agent finishes after the sum of all four jobs.
- Context. The orchestrator keeps the plan and the short results that pass the check. One agent keeps the full reading history of all four jobs.
- Tokens. You pay for every token that every worker reads and writes, plus the orchestrator's own. The orchestrated run usually costs more.
Orchestration can cut elapsed time and protect the orchestrator's context, but it usually raises total token use. Split work only when one of those gains matters.
A worker has no conversation history unless the orchestrator supplies it. A good assignment names the scope, the expected result, and what the worker must not change. A vague assignment often costs a second round trip.
Try the decision
For each job, choose one agent or several workers. Then compare your reason with the answer.
Rename one button in one file. The test suite checks the result.
Four patterns
Most work with subagents takes one of four shapes.
Fan-out
Independent parts run in parallel, for example one worker per module in an audit. The orchestrator draws boundaries so that no two workers touch the same files.
Pipeline
Each item moves through stages such as find, fix, and check. One item can be in review while the next is still in the find stage.
Judge and jury
A fresh worker tries to disprove each finding. The orchestrator keeps only the claims that survive an independent check.
Loop until dry
For a search of unknown size, the orchestrator sends new waves of finders until a wave returns nothing new.
What goes wrong
- Workers collide. Give them separate files or isolated workspaces.
- The orchestrator trusts raw claims. Verify findings before they drive a decision.
- The orchestrator rereads everything. That fills the context that the split was meant to protect.
- A small task gets split. The coordination costs more than it saves.
When to use it
Use orchestration in three cases:
- The reading will crowd one context window.
- Independent parts can run at the same time.
- A decision needs an independent check.
Keep small, sequential work in one context.
Reasoning effort controls how much one agent thinks. Orchestration controls how work spreads across agents. The two combine: a mechanical worker can run at low effort while the verifier runs at high effort.