Two agents editing the same codebase at the same time is not twice one agent. It’s a new failure mode. Agent A refactors an interface. Agent B, in its own session, is building a feature that calls that interface, on the old shape, because nobody told it the shape changed. Both are locally correct. Both pass their own checks. Together they produce a codebase that doesn’t compile, or worse, one that compiles and is quietly wrong.
That’s contamination, and it’s the thing that turns “I’ll just run more agents” from a throughput win into a mess. Getting parallel agents to actually help comes down to three disciplines: isolate them, give them a shared contract, and reconcile them on the way back. Skip any one and the collisions eat the speedup.
Why more agents multiply the problem instead of dividing the work
A single agent has one nice property: it sees everything it did. Its context is its own history. The moment you have several agents working at once, that property is gone. Each one sees its own window and nothing of the others’. They can’t observe each other’s changes, because “the other agent edited this file” is not a fact that exists inside any one agent’s context.
So the coordination that a single agent did implicitly, by remembering its own edits, now has to be done explicitly by something outside the agents. If that something is you, reading every diff and holding every collision in your head, you’ve become the integration bus, and you’re the bottleneck the parallelism was supposed to remove. This is the concrete texture of being the runtime by hand: you’re not writing code, you’re being the channel between agents that can’t see each other.
Discipline one: isolation
The first rule is that agents must not share a working surface while they work. Two agents writing to the same files in the same directory will corrupt each other’s state constantly, not because they’re bad but because neither can see the other’s uncommitted changes.
Isolation is what worktrees are for. Each agent gets its own checkout, its own branch, its own working directory. It can edit freely without stepping on anyone, because there’s no one else in its copy. The collisions don’t happen during the work. They’re deferred to the merge, where they can be handled deliberately instead of racing. Running parallel sessions across worktrees is the mechanical foundation of all multi-agent work, and everything else assumes it.
Isolation buys you safety during execution. What it doesn’t buy you is coherence. Two isolated agents can each build something sensible that contradicts the other, because isolation stops them from corrupting each other’s files, not from making incompatible decisions. That’s the next two disciplines’ job.
Discipline two: a shared contract
Isolated agents still need to agree on the things that span them: the interfaces, the invariants, the shape of the thing they’re both touching. If each agent invents its own version of the shared boundary, isolation just means they collide cleanly at merge instead of messily during work. Better, but not solved.
The fix is that the shared parts live in a contract both agents read, outside either agent’s session. The interface both are building against is specified, not improvised. The invariants both must respect are in the rules file both load. When Agent A needs to change the shared interface, that’s a change to the contract, not a private decision inside A’s window that B will discover by breaking.
This is where multi-agent orchestration and memory converge. The shared contract is exactly the memory that persists outside the chat: decisions and invariants that no single agent owns, that all of them read. Without that shared, external layer, “orchestration” is just several agents guessing at a boundary none of them can see, and the guesses won’t match.
And you should still expect divergence even with a contract, because a contract constrains without eliminating choices. Designing for that expectation, rather than assuming the contract makes everyone agree, is the whole point of accepting that agents will drift. Isolation and contracts reduce collisions. They don’t get you to zero. Which is why the third discipline isn’t optional.
Discipline three: reconciliation
Isolation defers the collisions to the merge. A shared contract shrinks how many there are. Reconciliation is where you actually resolve the ones that remain, and it’s the step people skip because it’s unglamorous and it’s where the real work of multi-agent development lives.
Reconciliation is not git merge and hope. It’s the deliberate act of bringing parallel branches back together and checking that the combination is coherent, not just that each branch was fine alone. This is precisely the locally correct, globally incoherent problem, and multi-agent work is its most acute form: you have manufactured, on purpose, several locally correct changes, and nothing guarantees they add up to a globally correct system.
A real reconciliation step asks the questions no single agent could: does Agent B’s feature still work against Agent A’s refactored interface? Did anyone break an invariant that only mattered across the boundary? Does the integrated result pass the criteria that the individual pieces passed in isolation? Reconciliation is verification applied to the seams, and the seams are exactly where parallel agents fail, because the seams are the one place no individual agent was ever looking. That combined check is a verification loop aimed at the integration, not the individual diff: a gate the merged result has to pass, not a claim any single agent gets to self-report.
The shape of it
Put together, orchestrating multiple agents without poisoning is a loop, not a launch. You isolate each agent in its own worktree so they can’t corrupt each other during work. You give them a shared contract so the things that span them are specified, not improvised. You reconcile at the merge, checking the combination and not just the parts. Then you do it again.
The thing to internalize is that the hard part of multi-agent work is not launching the agents. Launching is easy, that’s why everyone starts there and hits the wall. The hard part is the boundary between them: the shared contract they read and the reconciliation that catches what crossed the boundary wrong. Get isolation, contracts, and reconciliation right and more agents genuinely means more done. Get them wrong and more agents just means more collisions for you to referee by hand.
When two of your agents collide, do you find out at the merge or three commits later? Tell me on the forum.
Frequently asked questions
How do you run multiple coding agents at once without conflicts?
Three disciplines. Isolate each agent in its own worktree so they cannot corrupt each other’s files while they work. Give them a shared contract — the interfaces and invariants both read from outside either session — so the parts that span them are specified, not improvised. Then reconcile at the merge, checking the combination is coherent, not just each branch alone. Skip any one and collisions eat the speedup.
Can two AI agents safely edit the same codebase?
Not on the same working surface. Two agents writing to the same files corrupt each other’s state constantly, because neither can see the other’s uncommitted changes. The fix is isolation: each agent gets its own checkout, branch and directory through git worktrees. Collisions are deferred to the merge, where they can be handled deliberately instead of racing. Isolation buys safety during execution, though not coherence — that needs a shared contract and reconciliation.
What is contamination between parallel agents?
Contamination is when two locally correct changes combine into a broken whole. Agent A refactors an interface; Agent B, in its own session, builds a feature against the old shape because nothing told it the shape changed. Both pass their own checks, yet together they produce code that will not compile, or worse, compiles and is quietly wrong. It happens because no single agent’s context contains the fact that another agent edited something.
How do you merge work from multiple AI agents?
With reconciliation, not git merge and hope. Reconciliation deliberately brings parallel branches together and checks the combination: does B’s feature still work against A’s refactored interface, did anyone break an invariant that only mattered across the boundary, does the integrated result pass the criteria the pieces passed alone. It is verification aimed at the seams, which is exactly where parallel agents fail, because the seams are where no individual agent was looking.