Part 7 of 7 · Chapter 2 of 4

Subagents and Orchestration

Splitting a large job across several agents, and the failure modes that appear when you do.

Advanced14 min read

Worth reading first: Agents and Background Work

One agent working sequentially has a ceiling: the context window. Splitting work across several agents raises it — and introduces a new class of problem, because now they can disagree with each other.

Why split at all

Two reasons, and it is worth being clear which one you have, because they need different shapes.

Breadth

The work does not fit in one context. Auditing 200 files, or migrating every call site of an API. Split by item.

Confidence

You want independent opinions rather than more output. Three reviewers who cannot see each other’s conclusions. Split by perspective.

The shapes that work

1
Fan out, then merge
One agent per file or per module, all independent, then you combine the results. Works because the pieces do not interact.
2
Generate then verify
One agent proposes, a second one — with no memory of the first — tries to find the flaw. The second agent is the valuable one.
Ask the verifier to refute rather than to check. A checker agrees; a refuter looks harder.
3
Panel of perspectives
Same code, three agents, three different lenses: correctness, security, performance. Diversity catches what redundancy cannot.

What goes wrong

The failure modes are specific to parallelism, and none of them appear when a single agent works alone.

1
Conflicting edits
Two agents change the same file and the second overwrites the first. Fix: separate worktrees, or partition so no two agents touch one file.
2
Inconsistent decisions
Each agent invents its own naming or error handling because none of them can see the others. Fix: a shared rules file, and one agent that does a consistency pass at the end.
3
Confident agreement on a wrong premise
Three agents given the same flawed framing produce three flawed answers that reinforce each other. Fix: vary the framing, not just the count.
4
Cost that scales badly
Five agents is five times the tokens, and they are not five times more likely to be right.

Doing it by hand first

You do not need special tooling to try this. Two terminals and two worktrees is real orchestration, and it teaches you where the friction actually is.

Terminal

$ git worktree add ../app-auth -b agent/auth$ git worktree add ../app-billing -b agent/billing # one agent in each folder, on unrelated modules# then merge both branches and resolve anything that overlaps

Partition by module, so the agents cannot collide. If you find yourself splitting work that shares files, that is a signal the task wanted one agent, not two.

When not to bother

Orchestration adds coordination overhead — partitioning, merging, reconciling. For most tasks a single agent with a good prompt beats three with mediocre ones. Reach for it when the work exceeds one context, or when you want an adversarial second opinion.

Doing it because it sounds sophisticated is how you end up spending an hour merging three inconsistent implementations of something one agent would have finished.

Key takeaways

Split for breadth (by item) or for confidence (by perspective). Know which you are doing.
Generate-then-refute is the highest-value shape. Ask the second agent to break it, not to check it.
Partition so no two agents touch the same file, or use separate worktrees.
A shared rules file is what keeps parallel agents from inventing four conventions.
Agreement between identically prompted agents is weak evidence — vary the framing.
One agent with a good prompt usually beats three with mediocre ones.