Subagents and Orchestration

There are two reasons, and they need different shapes. Decide which one you have first.

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.

Each shape below only works when the three conditions above hold. They are ways of satisfying them, not ways around them.

1. 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. 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. 3

   Panel of perspectives

   Same code, three agents, three different lenses: correctness, security, performance. Diversity catches what redundancy cannot.

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

1. 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. 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. 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. 4
   Cost that scales badly

   Five agents is five times the tokens, and they are not five times more likely to be right.

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 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.

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.