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

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 — that don't touch the same files. Here, parallel worktrees are a real speed-up.
• Not worth it: several agents on one shared problem. 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. 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 constantly coordinate, they're really one task — give them to one agent.

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.