Subagents and Orchestration
Splitting a large job across several agents, and the failure modes that appear when you do.
Read 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
There are two reasons, and they need different shapes. Decide which one you have first.
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.
What has to be true before you split
Splitting work across agents is not automatically faster, for the same reason splitting work across people is not automatically faster: coordination has a cost. If the pieces are not separable, you pay that cost on top of doing the work, not instead of it.
Three things have to be true, all of them
- →The tasks are independent — neither one's answer depends on what the other decides.
- →The files are disjoint — no two agents will write to, or need the live state of, the same file.
- →You have a merge plan before you start — who resolves a conflict and in what order the branches land — not one you improvise once three diffs are sitting in front of you.
The shapes that work
Each shape below only works when the three conditions above hold. They are ways of satisfying them, not ways around them.
- 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.
- 1Conflicting 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.
- 2Inconsistent 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.
- 3Confident 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.
- 4Cost 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.
$ 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 overlapsPartition 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 for its own sake is how you end up spending an hour merging three inconsistent implementations of something one agent would have finished.
Key takeaways
- Parallel work pays off only when tasks are independent, files are disjoint, and you have a merge plan decided in advance.
- Split for breadth (by item) or for confidence (by perspective). Know which you are doing.
- Generate-then-refute works well here. Ask the second agent to break the plan, not just 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.
Quick check
Answer these to unlock the next chapter — 3 of 4 to pass. You can retake it anytime.
Answer every question to check.
Make a free account to read on
Every chapter is free — an account is how your progress, XP, and streak follow you from your laptop to your phone, and how you show up on the leaderboard. No payment, no trial.