If you want several AI coding agents working at once, the technical unlock isn't a bigger model or a cleverer prompt — it's a quietly brilliant git feature that has been around for years: the worktree. Understanding worktrees is the difference between "one agent at a time" and "a fleet running in parallel without stepping on each other."
What a git worktree is
A git worktree is a second working directory backed by the same repository, checked out to its own branch. One repo can have many worktrees, each with its own independent files on disk. The object database — all your history — is shared, but the working files are separate.
A single command, git worktree add ../task-a -b task-a, spins up an isolated checkout on a fresh branch in seconds — no second clone required.
Why one working directory breaks parallel agents
Picture two agents editing the same checkout at once. One renames a function while the other is mid-edit in the same file; a build kicks off against a half-applied change; a test run picks up someone else's work in progress. A single working directory is a single point of contention, and contention is where parallel work quietly corrupts itself.
One worktree per task = real isolation
Give every task its own worktree on its own branch and the problem disappears. Five agents across five tasks each have a private working directory; none of them can touch another's files or your main tree. If a run goes sideways, you delete its branch and worktree and nothing is lost — the failure is contained by construction, not by hope.
Integrating without conflicts
Isolation is only half the story; the work has to come back together. The trick is to merge in dependency order: a finished, passing branch is integrated into the base before any task that depends on it starts, so each new task builds on integrated work rather than a stale snapshot. When a merge does conflict, route that task to review instead of force-pushing through it.
Disposable by design
Because worktrees share the object database, they're cheap to create and cheap to throw away. Treat them as disposable: one per task, deleted the moment its branch is merged or discarded. That disposability is exactly what makes unattended, parallel runs safe to trust.
By hand vs having it managed
You can absolutely script worktrees yourself — add, run a setup script, merge, remove. The friction shows up at scale: tracking dozens of worktrees across several projects, running the right setup script in each, merging in the correct order, and cleaning up. That bookkeeping is precisely where an orchestrator earns its keep, turning the manual choreography into something you don't have to think about.
Worktrees are what turn "one agent at a time" into a whole fleet at once — safely.
Frequently asked questions
What is a git worktree?
A git worktree is a second working directory backed by the same repository, checked out to its own branch. You can have many worktrees from one repo, each with independent files, so work in one never disturbs another.
Why do AI agents need worktrees?
Because multiple agents editing one working directory would clobber each other. Giving each task its own worktree and branch lets agents run in parallel safely — and a bad run is discarded by deleting its branch, with nothing lost.
Do worktrees use a lot of disk space?
Less than full clones — worktrees share the repository's object database, so each one mostly costs a checkout of the files, not a second copy of all history.
How do parallel branches get merged back together?
In dependency order: a finished, passing branch is merged into the base before dependent tasks start, so each builds on integrated work. If a merge conflicts, that task routes to review instead of being forced.
Run agents in parallel, safely
Command Fleet gives every task its own git worktree and merges in dependency order — no clobbering, no lost work. Free for 7 days, no credit card.