Several agents in parallel
While an agent works, you wait. With worktrees several run side by side without overwriting each other. How that works, what subagents are good for – and why your bottleneck is usually not compute time but reviewing.
Boaz Lichtenstein
A coding agent needs ten to thirty minutes for a decent task. During that time you sit beside it. The obvious thought: start a second one. That works – under conditions.
The problem: one folder, two authors
Two agents in the same project folder work on the same files. One changes a function, the other reads the old version and overwrites it. Neither notices. On top of that comes the branch: a folder has only one active branch at a time, and if one agent switches it, the other suddenly stands in foreign code.
The solution: worktrees
A worktree is a second working folder of the same repository, on a branch of its own. Both folders share the history but not the files.
git worktree add ../store-search -b search-typos
git worktree add ../store-export -b export-csv
git worktree list
git worktree remove ../store-searchThe first line creates the folder store-search next to your project,
on the new branch search-typos. You start the first agent there, the
second in the second folder. Each branch becomes a pull request of its
own. Many agent tools now create worktrees themselves on request – this
is the principle behind it.
What can be parallelised
Two conditions, and both must hold:
No shared files. If two tasks change the same file, you get a conflict when merging – and that costs more time than the parallelism saved.
No dependency. If task B needs the result of task A, they run one after the other.
Good candidates: two independent bugs in different areas, tests for one module and documentation for another, a piece of research alongside an implementation.
The rule behind it: one writer per set of files. Agents that only read – search, analyse, review – can share a folder.
Subagents: hand off work, save context
A second form of parallelism sits inside the agents themselves. A main agent can hand sub-tasks to subagents: “Find every place where this function is called.” The subagent reads forty files; the main agent receives only the summary.
The gain is not only time but context: the forty files occupy the subagent’s working memory, not the main agent’s. The price is two handovers at which detail is lost – the subagent knows only what was in the brief, and the main agent only what is in the summary. Then there is cost: every subagent uses quota of its own.
Subagents make sense for broad searches and independent partial checks. They do not make sense for anything the main agent does itself in three steps.
The second agent as reviewer
The most useful parallelism is often not simultaneous: one agent writes, another with a fresh context reviews. The reviewer did not witness how the work came about and is therefore not anchored on the first one’s solution.
What matters is what you give it: the brief and the diff – not the first agent’s explanation. A reviewer handed the conclusion usually confirms it.
The real bottleneck
Agents generate faster than you can review. Three parallel agents mean three pull requests waiting to be read. Start more than you can review and you collect unread changes – and at some point approve one of them because the pile is pressing.
Hence the upper limit: as many agents as you can review results for thoroughly. For most people that is two, on good days three. What brings speed beyond that is not further agents but smaller tasks and acceptance tests that take part of the review off your hands.
How to measure whether an agent delivers good work at all is the way into the last path: Running agents.