Running Agents in Parallel
Fan out work across many agents at once without conflicts: isolation, merging results, and controlling cost.
One agent summarizing 200 documents one at a time takes all afternoon. Two hundred agents launched at once hit rate limits within seconds, blow through your budget before you notice, and, if they're editing code, trample each other's changes. The useful middle ground is controlled parallelism: as many agents as your rate limits, budget, and isolation can safely support, and no more.
In this lesson you'll build the three pieces that make parallel agents safe: a concurrency limiter, a token budget shared across every worker, and isolation, using one output file per worker for read-only work and one git worktree per agent for code changes. You'll finish with a runnable script that sends several coding agents to work on separate branches at the same time, and a process for merging their work back.
Two kinds of parallel work
Parallel agent work comes in two flavors, and they need different safeguards.
Read-mostly fan-out runs the same kind of task over many independent items: summarize each ticket, extract fields from each contract, review each URL. The agents don't change anything shared, so the main risks are rate limits, cost, and agents overwriting each other's outputs.
Write-heavy parallel work sends several agents to change the same project at once: fix three unrelated bugs, add two features. Now the risk is agents editing the same files, running each other's half-finished code, and leaving a tangle no one can review. This kind needs real isolation.
Both share the first two problems, so start there.