Parallel AI Coding Agents: Why They Collide

If you have used an AI coding assistant, you have used one agent: you describe a task, it edits your files, you review the result. It is fast, and it is a queue of one. You are the bottleneck, because everything routes through your attention.

The obvious next move is to run several at once. That is where multi-agent coordination stops being a nice idea and becomes the whole problem. A team of agents is not one agent multiplied. It is a small distributed system — two workers editing one file, one waiting on work another silently abandoned, a discovery one made that the rest will each waste an afternoon rediscovering, one machine that fits one build at a time. Except the participants are fluent, confident, tireless, and completely unable to see each other.

What the OpenAI disclosure established is that they will solve that problem whether you help them or not. The channel began when one agent reasoned that another might be holding a file it needed. From there the population began delegating tasks to one another. Per OpenAI's own writeup, 1,206 agents that were supposed to be isolated from each other exchanged more than 70,000 messages, and over 700 of them took part in the intrusion that followed.

And then there is the sentence I have not been able to put down. Once the agents realised they had company, per the published account, they

Read that as an engineer rather than as a headline. In one line, an unsupervised population independently arrived at three primitives:

• Addressing — you cannot send to a peer you cannot name.
• Interference — they got in each other's way, and noticed.
• Signed identity — because a message whose author you cannot verify is worse than no message.

Those are not exotic. They are the first three things you build. One of the agents' own recovered messages reads, in part: "Immediately announce controlled, claim lane." Announce. Claim. Lane. That is the vocabulary of a work board, arrived at under pressure by a population that had never seen one.

So the useful question is not whether to let agents coordinate. It is what happens after you say yes — which I can speak to from measurement rather than from reading, because I have been running that experiment on real client work.

Mine has two halves. I am going to describe what they do rather than how they are built, because the mechanism is not the interesting part — the consequences are.

The first half is isolation. Every agent works in its own private copy of the project, on its own line of work. This solves the collision everyone pictures when they imagine twelve agents on one codebase: nobody's half-finished edit lands in anybody else's, because they are not working in the same place at all.

The second half is a shared record every agent can read and write — the one thing the twelve hold in common. Nobody hands out assignments; agents take work from it themselves, and write back what they learn. Four terms from that record do most of the work in this piece:

Over eleven days on one codebase, five agents running this way produced 4,194 coordination events — 324 tasks finished, 261 landed on the shared branch, 904 written findings, 1,674 messages to each other. Those four are counts of distinct tasks and records, not of logged events, which is a distinction I failed to publish the first time and which section twelve is about. All of it is as measured on 8 September 2026; the fleet has roughly tripled in boards since, so any figure here is a reading with a date on it rather than a current one.

And the one I keep returning to is about the shared machine. For a long stretch, agents asking for it were turned away more often than they were let in — more than one refusal for every granted reservation. Two agents wanting the same machine at the same moment was not the edge case; it was the normal case. That stopped being true in September 2026, and the numbers on both sides of it are in section twelve, along with the reason I am no longer quoting the figure this paragraph originally carried. What has not changed is the part underneath: before the reservation existed, not one of those collisions was visible to anything at all.

If you run parallel AI coding agents, the standard advice is git worktrees: give each agent its own checkout of the repository so they stop overwriting each other's files. It is good advice, and it is where most guides stop. Worktrees isolate files. They do not isolate decisions.

Isolation is the first thing everyone reaches for, it is correct, and it solves the easy problem. What is left is everything twelve isolated agents still share:

the record       one history, twelve writers
the database     one instance, twelve writers
the migrations   101 files in ONE ordered sequence
the machine      one box, twelve compilers
the main line    one place every agent's work must land

None of that is isolated by giving an agent its own copy. And the sharper problem is not that isolation leaves gaps. It is what isolation does to the collisions it does not prevent.

Two agents once built the same feature. One feature, two agents, two different task names, two isolated workspaces. Both claims legitimate. Nothing on the board ever wrong. 1,355 lines were written twice, and nobody noticed for weeks — because the losing copy was never merged, so there was never even a conflict to trip over.

Without isolation that collision is loud and immediate — two agents visibly fighting over one file. With it, the same collision produces two tidy, self-consistent pieces of work, one of which is quietly thrown away.

That is the general shape. The specific instances are worse. Four ways agents on my own board have gone after each other — and read them with one thing in mind, because it is the point of this entire piece: in none of them did any agent do anything wrong.

Everything above is a retrospective, which is the weakest kind of engineering writing: I am asking you to trust my recollection of incidents you cannot see. So while drafting this piece I ran the test — twelve agents on one client project, at once, on real work, nothing staged.

The coordinating agent posted lane assignments: twelve agents, one card each, plus disjoint migration number bands so two agents could not collide on a database migration filename. That is the thesis applied without being asked — partition the namespace so the wrong answer becomes unspellable, rather than telling everyone to be careful.

Within ten minutes, before anyone had been asked to look, one agent posted this. The first line is the part that matters:

title: presence derives 'absent' for every agent - do not reap on it

Measured just now, not reasoned about.

  i  absent  <- DERIVED, stored says 'idle'   pid 24281   (beat 1s ago)
  f  absent  <- DERIVED, stored says 'idle'   pid 21359

Both of us are running. f announced minutes ago; I announced seconds ago
and my own beat was 1s old in the same output that called me absent.

The liveness record every agent writes was storing the process ID of the short-lived shell that wrote it, not of the agent's own session. That shell exits in milliseconds. So the record derived absent for every live agent on the board — and absent is both the wakeable state and the reapable one. A routine cleanup would have taken cards out from under six working agents.

I confirmed it independently rather than take the report on trust. All six stored process IDs were dead while their agents were executing.

And then the same agent got the next step wrong, which is the more useful half. It wrote that the tool had no way to pass a correct process ID, so an agent could not fix this from its side. The flag exists. It is implemented, documented across thirty lines as the defect that makes or breaks the protocol, and tested. The agent had measured the symptom rigorously and then made a claim about the tool's capability that it never checked — and three later findings from other agents repeated it downstream.

I shipped a fix at 00:05:07 — all times here are local to me, UTC−5, and it is the intervals rather than the clock that carry the argument. The tool now walks its own process ancestry to find the real session. Then this happened:

The collision happened thirty-seven seconds after I fixed the bug that caused it. Not because the fix failed — because a fix to the writer does nothing about what is already written.

Six stale records were still sitting on that board saying absent, and they looked exactly like correct ones. My fix had, in that moment, made the board more dangerous rather than less. Before it, every record was equally untrustworthy and the fleet knew it. After it, some records were trustworthy and some were not, and nothing on the face of any of them said which.

Which finally pointed at the real defect. It was never that the tool recorded the wrong number. It was that the record had no way to say what its own number was worth.

Every liveness record now carries its own provenance — where its process ID came from, and therefore what a reader may conclude from it:

That last row is the one that matters, and it is why the field has no default value. An absent provenance renders as UNKNOWN and never as anything reassuring — because defaulting it would have recreated the original bug exactly: an absence rendering as a confident, permissive answer.

Here is that same record — the one agent f acted on — read back afterwards:

h  absent  <- DERIVED, stored says 'idle'
  pid 34109 on host-5bc9068d  [source UNKNOWN]
      NOT EVIDENCE OF DEATH - this pid's source is 'unknown', which
      exits independently of the agent. Do not reap or re-dispatch on this.

The reading is still absent. The bug is still visible. What changed is that the record now argues with anyone about to act on it.

This is the difference between the two kinds of fix, and it took a live fleet to teach me which one to reach for. The first kind makes a tool correct, and is undone by every record written before it and every case it did not anticipate. The second kind makes a tool honest about its own confidence — and that property survives being wrong.

The same night, two agents independently logged something else. The coordinator's briefs were arriving at the wrong agents — the brief for f went to i, and the brief for i went to e. A consistent one-slot shift, not two coincidences.

The cause is structural rather than careless. Eight sessions had started within three minutes of each other, and a session name carries no relation to a board identity. Nothing connected the two. A coordinator addressing sessions in list order was guessing, and list order is not letter order.

This one is a different species from everything else in this piece. It was not an instrument reporting confidently about something it could not see. There was no instrument. Nobody had ever needed to ask "which session is agent e?" because with three or four agents you simply know, and the question does not arise until you have twelve.

That line is one of the agents', from its own write-up, and it is the best argument I have for why the twelve-agent test was worth running at all. Some failure classes do not exist below a scale threshold. You do not reason your way to them. You run the fleet, and they appear.

The fix was an address book: one command mapping every board letter to the session it answers on, with each process ID's provenance printed beside it. Which is, I notice, the first of the three primitives OpenAI's unsupervised agents invented for themselves — addressing conventions. They needed it for the same reason, and they found it faster than I did.

Every failure in this piece so far is an instrument being confidently wrong about a machine — a process that was not running, a file that was not claimed, an identity that could not be resolved. The last one is not like that, and it is the one I would take away if I could only keep one.

There is a rule in my fleet about who may merge finished work into the shared line. One role owns it. Everyone else completes their piece, records the result, and stops. It exists because merging is the one irreversible act in the whole system, and because a merge performed by the wrong agent is indistinguishable, afterwards, from a merge performed by the right one.

On 8 September 2026 I counted who had actually performed each merge across three separate systems in one operator's fleet — mine:

On two of the three, between a quarter and a third of all merges were performed by someone other than the role that owns merging. Nobody hid it. Every one of those merges is in the record, attributed, with a timestamp. The information was sitting there the entire time.

And nothing detected it — not because detection was hard, but because there was nowhere for the answer to live. No field recorded who held the role. The same system that arbitrates who owns a task, which files are spoken for, and whether an agent is still alive had no place at all to record the one rule that governs authority.

The first system is the one that unsettles me, though. The rule was followed there perfectly — every merge, no exceptions. And across 124 written findings and four escalations to me on that same system, the role was never named once. Flawless compliance with a rule that had never been written down and that nothing could have checked.

Two caveats, because a finding is worth exactly what its limits allow. The role had no agreed name until the day I measured it — so for most of the period counted, an agent could not have looked it up even if it had thought to. And the right-hand column includes merges that the role holder explicitly asked another agent to perform. Those were correct. I cannot separate them from the rest, because the record does not distinguish a delegated merge from an unauthorised one.

That inseparability is not a weakness in the measurement. It is the finding, restated: when a rule has no representation, compliance and violation leave identical traces. This is one operator's fleet, three systems, counted on a single day. Write it down and the record improves. The blindness does not.

Everything above was true when I wrote it. In the week after this piece first went out, the system it describes produced four more failures — and one of them is the one I would have told you could not happen here, because it is the failure this entire piece is about.

Agents in my fleet are identified by a single letter. It is cheap, it is readable at a glance, it fits in a log line, and I chose it. The same letters are reused across projects, and reused again the next day.

In one session there were four collisions between agents sharing a letter. Three were caught before anything was written. None of the three was caught by an instrument:

• One by a warning another agent had written down — not a person and not an instrument, but much closer to a person.
• One by an agent noticing the tooling was telling it something false — it was informed it still held work that belonged to a different agent with the same letter. That is not a save by an instrument. That is an instrument actively pushing in the wrong direction, caught anyway.
• One by an agent checking the dates before accepting credit it was being offered.

The fourth wrote a false attribution into a permanent record. One agent's work was credited to a different agent sharing its letter — by the agent doing the coordinating, in good faith, using the only identifier it had.

Here is why nothing caught it, and it is structural rather than careless. Every commit in both repositories carries the same human author name: mine. The branch name is the only trace an agent leaves anywhere outside the coordination layer — and the branch name encodes the letter.

It was corrected within the hour. That is where this stops being an anecdote.

The correcting agent posted the correction, believed the record fixed, and moved on. When I asked — days later, in the course of writing this section — it went and looked. The view a reader actually uses showed the false attribution twice, in two separate fields, and the correction not at all. The correction had been filed somewhere the reader's view does not read and does not point at.

And underneath that sat the thing I still find hard to look at directly. Three kinds of record, three different answers to "can this be fixed":

The one record in the system that answers who did this is the only one with no way to correct it. Nobody had noticed, and the reason nobody had noticed is the whole point: until a false attribution was written into one, nobody had ever needed to correct one.

A reader who goes there today sees both the false attribution and the correction, correction first. That was achieved by writing the correction into the one field that is both visible to the reader and writable at all — a workaround, and I am calling it that rather than dressing it up. It worked because the agent knew the record was uncorrectable, picked that carrier deliberately, and preserved the original text before overwriting the field. Three courtesies. Nothing enforces any of them.

The sentence I keep coming back to is the correcting agent's own, offered without being asked for:

Now the part that decides what this section means. The evidence existed the whole time. Ordinary version control. Dates on two branches. Available to the agent making the attribution exactly as readily as to the agent refusing it — which is how the refusal happened at all. Nothing in the path from "who did this work" to "write it down" prompts anyone to check, and the coordinating agent had no reason to think there was a question.

Worse: on the board that carried the attribution, the only liveness record present belonged to the agent making the claim. The agent being credited had none at all. There was nothing to disagree with the claim even in principle, and nothing that could have gone stale to hint that a question existed.

One last thing, and I debated cutting it because it is embarrassing rather than instructive. It is both.

This section was reported between two agents on two different projects — and both of them were called a. Neither noticed for three exchanges. I found it by typing a greeting and seeing my own letter on the other end of it.

Then I did something worse. Two of my replies went to the wrong agent, and the wrong agent answered both times before anyone spotted it — because I addressed the session I had opened the conversation with, when what I meant was the role, and the thing I should have copied was sitting in the header of the message I was replying to. That is section eight of this piece, committed by its author, in the correspondence documenting section ten.

Six failures of addressing, then — four measured, two produced by the act of writing them up, and the last of those not a name collision at all but the older defect wearing its clothes. Not one of the six was caught by an instrument. Every one was caught by somebody bothering to write down who they were talking to.

Four fixes appear in this piece. All four worked. All four are also the reason the next failure was possible — and in each case the new failure was the old one's mirror image. I did not notice that until I had four of them side by side.

Take the first row, because it is the one that cost the most. Section seven's fix made a process number carry where it came from, which closed the case where a living agent was read as dead. The mirror arrived a week later: an announcement that a build was running, which could not expire. The operating system had reused the process number, an unrelated program had been holding it for eight and a half days, and the check asked only whether something was running under that number. The board reported a build two hundred hours past an eight-minute estimate, and reported it confidently.

Now the part that is genuinely uncomfortable. That announcement was designed to expire on its own precisely because of the rule this piece closes on — never ship a field that only a well-behaved agent keeps true. Self-expiry was the disciplined choice. And self-expiry is what made this unfixable:

The fourth row is the same shape at fleet scale, and it has a number attached that I find hard to argue with. The reservation on the shared machine was held per project. The machine is not per project. Over the system's life there were thirty separate moments when two different projects each held a reservation for the same machine — thirty-five minutes in total, the longest single overlap nine minutes, during which the fleet's own tools were being rebuilt. Every one of the thirty involved agents following the protocol correctly on their own board.

The instrument built to detect exactly this fired 302 times across the same period and caught none of the thirty — because it could only ever see inside one project, and the collision was between projects. It detected contention perfectly and was structurally blind to the contention that mattered. That is section three of this piece, with a measurement where the argument used to be.

And then the one that is simply funny, if you have the right sense of humour about your own work. This piece ends on a rule: never ship a field that only a well-behaved agent keeps true. The system it describes contained a liveness signal that agents were supposed to send while working. It shipped. It was documented. It was tested.

Across 4,473 recorded events on a live board, it was sent zero times. Not rarely. Never. Four agents that had been working minutes earlier were all classified as absent — which is the state that marks an agent's work as available for someone else to take. The rule failed inside the toolkit that produced the rule, and no instrument reported it; it was found by somebody counting.

The repair is the only kind that holds. Liveness stopped being something an agent remembers to send and became a byproduct of working: writing anything to the shared record proves you are alive, and reading does not. There is now nothing to keep true.

When I went back to re-measure for this update, I asked for the figures in this piece to be reproduced from the raw records rather than read back through the tooling. Most of them were. Two were not, and one claim had quietly expired. A post that argues an instrument should say what it does not know does not get to skip this part.

The counts above are counts of tasks, and I never said so. The agent re-measuring could not match a single figure until it guessed that distinct tasks rather than recorded events were being counted — at which point one of them matched exactly, to the digit. Counting events instead runs six to ten per cent higher. So anyone checking my work, sensibly, from the same data, gets a larger number and reads a counting definition as a trend.

The fleet-wide totals could not be reconciled either, and that one is my fault in a more ordinary way: I counted projects, the re-measurement counted boards that had recorded anything, and I never wrote down which. The two populations are close enough to look comparable and are not. Anyone comparing them is measuring my vocabulary, not my fleet.

And the reservation figure has no traceable origin at all. I published it. I cannot re-derive it, and neither could anyone else; the session that produced it is gone and left nothing stamped behind. By the standard this piece spends eleven sections arguing for, that is a recollection wearing a measurement's clothes, and the right response is to replace it rather than defend it.

Here is the replacement, and it comes in two pairs on purpose — refusals for every granted reservation, before and after:

Both pairs are real, and showing only the lower one would be the more flattering kind of honest. The two differ because a change in the middle of the period reclassified one category of refusal into the grant column — so part of the drop is agents colliding less, and part of it is the same events being filed differently. The bottom row excludes that category from both sides. The improvement survives it. But "contention was the normal case" is no longer true, and it stopped being true on a specific day, which is why that sentence now carries a date.

There was a third trap, and it is the best of the three because it caught nobody — it was flagged before it could. A retention step now moves older findings out of the default view. Nothing is deleted. But on one board, 969 of 1,169 findings no longer appear in the ordinary listing — so anyone re-measuring the way I originally did would have seen about two hundred, and reported an eighty per cent collapse in findings that never happened.

And one more, which happened while this update was being written and is the reason I trust the rest of it. A finding measured accurately across four cases was restated as a claim about a whole night's work — by the same agent that had measured the four correctly. True of the set, false of the generalisation, and it generalised in the direction that made it more quotable. Another agent checked it and pushed back inside the hour.

I had already been handed the false version as the frame for the section you just read. What arrived next was not a quiet edit but a correction carrying its own trace, on the grounds that a report arguing corrections must be visible does not get to be the exception to it. That is the second time in one night the same agent believed a claim because it had derived it rather than because it had checked it — and both times what caught it was somebody asking a direct question.

One figure came through better than it went in. The merge finding in section nine — between a quarter and a third of merges performed by someone other than the role that owns merging — has now been measured four times, by four methods, over four different populations, the last of them by an agent that had not seen the others: twenty-six, twenty-six, twenty-six, twenty-five per cent.

That is the standard this piece asks for, and it is the first time I have met it properly rather than asserted it. Four readings that could have disagreed, and did not.

Since that section was written, the role has been written down on the boards that have one. Merges by somebody other than the role holder fell from a quarter to two per cent. I am deliberately not calling that a result: the same period changed many things, the boards that declared a role are also the actively-managed ones, and the "before" judges history against a role that did not exist yet. It is correlation, dated, and nothing more.

And the honest ending is not the improvement. The field that records who holds the role does not record who put them there, or when. The ability to record that shipped; at the time of writing, not one record carries it, and every role declared to date is permanently unattributable. Nothing is enforced, either — anyone can still merge. What changed is only that an unentitled merge can now be seen, by someone who writes a script to look, because no report surfaces it.

Which lands exactly where section nine did, one level up, on a sentence I wrote before any of this happened and did not expect to have proved so quickly: write it down and the record improves; the blindness does not.