When parallel AI agents
corrupt each other's work

One time we set several AI coders loose on a backlog at once, each on its own task, figuring that running them in parallel would be many times faster.

When the results came in, the very first PR had three files in it that had nothing to do with its task. They belonged to a different task another agent was working on.

The cause was not that any one AI made a mistake. It was that we let all of them work in the same directory. When several agents edit files in one shared place at the same time, the work collides. Whoever saves last writes over the others, and when an agent gathers its changes to submit, it grabs everything that moved in the directory, even the half that was not its own work.

The lesson: keeping work from colliding is not each worker's job. It is the orchestrator's job.

Part 1Many agents, one directory, mutual corruption

When the backlog is big, letting several AI agents go at once sounds like a good idea, and it is, as long as each one has its own place to work. The trouble starts when they all share the same place.

A codebase is like a single desk. One person working one task at a time is fine. Sit four or five people at the same desk, each pulling out and changing things at once, and of course the work gets mixed up, not because anyone is clumsy, but because there is only one surface.

With AI it is sneakier, because it never complains that its stuff went missing. It just keeps working on top of the directory state another agent just changed, and when it is time to submit, it scoops up every change it sees into one box. A PR that should hold one file ends up carrying other people's work too.

Part 2Why "tell them to be careful" doesn't work

The first fix people reach for is to tell every agent "don't touch other tasks' files." But that is staking safety on each one's discipline.

Hope is not prevention. As long as every agent can still reach the same files, the chance it brushes the wrong one is still there. Every time you let it run again, the risk comes back. Safety that depends on every agent doing the right thing every single time is not safety. It just hasn't broken yet.

This has to be fixed in the structure, not the instructions. If an agent has no way to even see or touch another's work, collision is not a "please don't"; it becomes impossible from the start.

Part 3The fix: one worktree per task

The good news is git already has a tool for this, called a worktree: a separate working directory that points back at the same repo but sits on its own branch. Different folder, different branch, no overlap.

The key is who creates it. The orchestrator, the thing handing out the tasks, must create a separate worktree per task, branched off main, before sending an agent in. Don't leave each agent to set up its own workspace, because handing that to the worker just stakes things on discipline again.

Set up this way, each AI opens to nothing but its own task. It cannot write over anyone, because the others' files were never in its view to begin with. When it gathers its work to submit, all it can grab is what is in its own folder.

The real result after switching to this: a final wave of 13 tasks running in parallel produced 13 clean single-file PRs, all 13, where before the work had been jumbled into one PR. The difference did not come from telling the AI to be more careful. It came from there being no way for it to reach anyone else's work.

Part 4The bigger principle

This does not stop at files. The same principle, that isolation is the orchestrator's job, applies to privileges too.

When we let an AI worker open its own PR, it hit the box's safety gate, the same gate that blocks dangerous commands like rm -rf. The wrong fix is to unlock the gate so it can pass, because that weakens the gate for the whole system just to smooth one thing over.

The right fix is to move the work that needs a privilege to whoever should hold that privilege, split by level. The worker does its judgment work in its sandbox: fix, commit, push. The higher-privilege work, like opening the PR, goes to a trusted orchestrator. And the actual merge stays a human's job. The gate never loosens at all; the work just moves to the right hands. Which work runs on its own and which waits for a human is the same line I wrote about in what AI decides alone and what a human signs off on.

Both cases are the same rule: don't hope each agent behaves; design it so misbehaving is impossible from the start.

Part 5Apply it

If you are about to run several AI agents at once, ask one question first: does each one really have its own place to work, or are they all sharing one?

If they are sharing, don't run them in parallel yet. Separate their spaces first: one worktree per task, branched off main, created by the orchestrator, not left to the worker. Then send the work in.

Take the principle to anything that is shared, whether files, privileges, or other resources. If several agents can reach the same thing at the same time, sooner or later they collide. The reliable fix is never asking everyone to be careful; it is designing them to be separate from the start.

This is one layer of the full production AI agent architecture (7 layers).