Run parallel agents with git worktrees

There's a real version of "run agents in parallel" that works, and it's not the swarm-on-one-problem trap. It's several agents doing genuinely independent work, each in its own isolated workspace, merged back cleanly when they're done. The thing that makes it safe is an old git feature most people have never used: worktrees.

Here's how worktrees turn parallel agents from a merge nightmare into a clean pattern — and when it's actually worth doing.

Why parallel agents collide

Point two agents at the same repo and let them work at once, and the failure is immediate and physical. They edit the same files. One saves over the other's changes. They leave the working tree in a half-and-half state neither can reason about. You get merge conflicts, race conditions, and corrupted state — not because the agents are bad, but because they're sharing one filesystem with no idea the other exists.

This is the practical reason a swarm on one problem fails: even setting aside contradictory reasoning, they can't physically share a working directory without trampling each other.

Git worktrees: isolation without a second clone

A git worktree is a second working directory attached to the same repository, checked out to its own branch. You can have several at once, each in its own folder, all backed by the same repo history — without cloning the whole thing again.

# from your repo, create an isolated worktree on a new branch
git worktree add ../feature-billing -b agent/billing
git worktree add ../feature-search  -b agent/search

Now ../feature-billing and ../feature-search are completely separate working directories. An agent in one cannot see or touch the files of the other. As the guides on git worktrees for parallel agents put it, they give each agent complete filesystem isolation without duplicating the repository — lightweight, fast, and clean.

Stuart Leo

A worktree gives each agent its own room. They can all work at once because none of them is in anyone else's space.

One agent, one worktree, one branch

The rule that makes this safe is simple: one agent, one worktree, one branch. Each parallel agent gets its own isolated directory and its own branch to commit to. No agent shares a working tree with another. No agent commits to main directly.

This maps cleanly onto the lead-agent idea: one lead agent per surface. Here, each worktree is a separate surface, so each gets its own lead. They run at the same time because they're working on different things in different places.

Sequential merges back to main

Parallel execution, sequential integration. The agents work concurrently in their worktrees, but you bring the results back one at a time:

1. Each agent finishes its task and its branch passes its tests.
2. You review and merge one branch to main.
3. You merge the next, resolving against the now-updated main.

Merging sequentially keeps integration sane — you're never trying to reconcile three sets of changes at once. Isolation first, integration second. (And when you're done, git worktree remove cleans up.)

That shape has a name, and it's worth knowing because it generalises well past worktrees. Independent agents running at the same time is a fan-out. The point where their results come back together — the merge, the integration brief, the PR — is a barrier. The worktree itself is isolation: it stops one agent's mess reaching the others. Fan out, isolate, barrier. Nearly every genuinely parallel run I do has that shape, whether or not git is the thing doing the isolating.

Once you can see it, you start noticing it was already in your plans — the shape of the work is a graph, and most people are drawing it as a queue.

When parallel is worth it (and when it isn't)

Worktrees solve the mechanics of parallel work, but they don't change the judgement about when to parallelise:

• Worth it: genuinely independent tasks — separate features, separate services — where no edge connects them and no surface is shared. Here, parallel worktrees are a real speed-up.
• Not worth it: several agents on one shared surface. Isolation can't fix that, because the conflict is in the reasoning, not just the files. That's still the anti-pattern, worktrees or no worktrees.

The test is independence, and independence has two halves. Is there an edge — does one agent's output become another's input? And is there a shared surface?

That second word does more work than people expect, because a worktree only isolates the filesystem. A surface is everything an agent mutates or contends for: files, yes, but also data, a rate-limited external API, a deploy target. Two agents in two spotless worktrees still collide if they both write to one staging database. That's false independence, and it's the version that bites — nothing in either brief says the surface is shared, so nobody sees it coming.

And parallelism buys breadth, not judgment. If two tasks could be done by two people who never need to talk, they can be two agents in two worktrees. If they'd need to coordinate constantly, they're really one task — give them to one agent. When the work is exploratory and I don't yet know what I'm looking for, that's one agent too, no matter how many worktrees I could spin up.

Give each parallel agent its own worktree, then merge sequentially — isolation first, integration second.

Start here: see how agent teams work, multi-agent vs single agent, or read the method.