What Parallel AI Agents Cannot See, and How to Fix It

Sixteen coding agents, one C compiler, one bug. Anthropic researcher Nicholas Carlini expected roughly sixteen times the progress. He got one agent's worth of work, plus fifteen agents' worth of burned tokens.

The cause was a specific, nameable failure.

Parallel AI agents inside one stage cannot see each other's in-flight edits to shared state. When two agents touch the same file, record, or task at once, whichever writes last wins, and the other agent's fix disappears with no error. Partition the work so agents can't collide, or isolate each agent's copy and reconcile afterward.

What Can Parallel AI Agents Not See?

Each agent in that setup reads the current state, makes its change, and writes back. No lock, and no error when another agent already wrote to the same place first, so the last write wins and the earlier fix disappears.

If you have not yet decided a job needs more than one agent at all, that decision comes first. When to use an AI agent instead of one prompt covers it, and routing is what sends the job to the right one once you know more than one exists.

What Happened When Anthropic Ran 16 Coding Agents?

Carlini's team built a Rust-based C compiler from scratch, aiming for it to compile the Linux kernel, and ran 16 instances of Claude Opus 4.6 against the codebase at once [1].

For most of the two-week build, a lock scheme kept them apart: an agent claims a task by writing a text file to current_tasks/, so one agent locks current_tasks/parse_if_statement.txt while another locks a different file [1].

The kernel compile step broke that. It is one large, unsplittable task, and Opus 4.6 could not get a 16-bit x86 code generator working for the boot sequence. Every agent hit the same bug:

"Every agent would hit the same bug, fix that bug, and then overwrite each other's changes. Having 16 agents running didn't help because each was stuck solving the same task." [1]

Sixteen agents produced one agent's worth of surviving work. The other fifteen runs were not wasted time in the sense of doing nothing; they each found a real fix, and each fix erased the one before it with no warning.

Why Does This Happen? The Last-Write-Wins Race

Name the mechanism, not the symptom. This is a last-write-wins race: several processes read the same state, each computes its own update from what it read, and whichever writes last is the one that survives. The other computations are not merged, flagged, or logged as lost. They are gone.

Three things produce this:

• Shared state
• More than one writer
• No lock on it

Any framework running "concurrent" agents against a shared file, a shared database row, or a shared ticket has all three unless something explicit stops it.

How Did Partitioning Fix It?

Carlini's fix split the failure into pieces small enough for the existing lock scheme to divide. He wrote a test harness that compiled most of the kernel with GCC, a known-good reference compiler, and handed Claude's own compiler only the files GCC's output couldn't explain [1]:

"I wrote a new test harness that randomly compiled most of the kernel using GCC, and only the remaining files with Claude's C Compiler. If the kernel worked, then the problem wasn't in Claude's subset of the files." [1]

That turned one shared, monolithic bug into many separate, file-scoped bugs. Each agent went back to locking its own file, and the collision stopped.

The other half of a partition scheme is what happens when the split is wrong. A lock file does not prevent a bad partition; it turns a bad partition into a merge conflict a person can read, instead of a silent overwrite nobody notices until the tests fail three days later.

What Is Isolate, Then Reconcile?

Partitioning needs you to know the boundaries in advance: which file, which row, which ticket belongs to which agent. Harvey, the legal AI company, builds document-editing agents for a case where that is not knowable up front, because two sub-agents can legitimately both be assigned to edit the same clause of the same contract.

This fix does not avoid the collision. It isolates the work, then reconciles it:

"Sub-agents can search and edit copies of the document independently without seeing each other's changes. When they finish, a reconciliation step auto-merges non-conflicting edits." [2]

Each sub-agent gets its own private copy of the whole document. Nothing is shared while the work is happening, so there is nothing to overwrite.

Once every sub-agent finishes, the copies get merged: edits that touch different parts of the document merge automatically, and a real conflict, two sub-agents editing the same clause, gets surfaced to an orchestrator agent to resolve rather than silently dropped [2].

Harvey measured this against their earlier architecture, which had dispatched one-shot sub-agents to process document chunks in parallel:

What Harvey measured	Change vs. the prior architecture
Edit accept rate	up 40% [2]
Queries per weekly active user	up 70% [2]

This generalizes past documents. Give each agent its own draft, then merge at the end, and the same pattern works for any job where agents produce overlapping output: a shared spreadsheet, a shared codebase, a shared customer record.

The reconciliation step is the part that has to exist somewhere, whether that is a merge algorithm, an orchestrator agent, or a person reading a diff.

Why Do My Own Agents Run Blind to Each Other Too?

My own AI office has a second, different reason parallel agents can't see each other, and it is worth separating from the failure above because it is not a bug.

Inside one stage, my specialists run at the same time on the same request:

# orchestrator/graph.py, specialists() -- one concurrent stage
results = await asyncio.gather(*(runner(role, stage_state) for role in pending))

The docstring above that line says why: "Inside a stage the specialists run concurrently and cannot see each other. Between stages the accumulated responses are threaded back into the state."

Growth and Engineering never share a live file mid-run the way Carlini's 16 agents did. They share nothing until their stage finishes, and only then does the next stage's specialist read what came out of it. So when Growth rewrites a page and Engineering lands it, Engineering is reading Growth's finished output, never a page Growth is still mid-edit on.

I built that checkpoint on purpose. Anthropic's agents and Harvey's sub-agents shared live state with no lock, and that's what let them overwrite each other.

My specialists share no live state at all until a stage ends, so there's nothing for two of them to collide on. Both are "what parallel agents can't see," but only one of the two needs a partition or a lock to fix it.

What Should You Check Before You Fan Agents Out?

Three questions, before you add a second agent to any job:

1. What could two agents in this pass both touch? Name the file, the database row, the ticket, or the customer record. If you can't name one, you likely have nothing to partition.
2. Do you have a partition scheme, or a lock, so a collision is loud? A partition with no lock behind it is a bet that you drew the boundaries right the first time.
3. Does "concurrent" in your framework mean isolated until a checkpoint, or shared live state with no lock? The first is safe by construction. The second is the setup Anthropic's 16 agents ran into, and it needs a partition or a reconcile step before you add a second writer.

Quick Recap

• Parallel agents inside one stage can't see each other's in-flight writes to shared state. No lock means the last write wins and every earlier fix disappears with no error.
• Anthropic ran 16 coding agents on a C compiler build. They stayed apart with a file-lock scheme until they all hit one unsplittable kernel bug, then each one's fix overwrote the last [1].
• You partition a shared failure into separate, file-scoped problems a lock can then divide. A lock doesn't stop a bad partition, it turns it into a visible merge conflict instead of a silent overwrite.
• Harvey's isolate-then-reconcile gives each sub-agent its own copy, auto-merges what doesn't conflict, and routes genuine conflicts to an orchestrator agent. Edit accept rate rose 40%, queries per weekly active user rose 70% [2].
• My own office's specialists run blind to each other inside a stage on purpose. They share nothing until a stage ends, so there's no live state for two of them to overwrite.
• Before you add a second agent to any job: name the shared resource, confirm you have a partition or a lock, and know whether "concurrent" in your tools means isolated or shared.

Start Here

The intake at daisyguti.ai/work-with-me is about nine questions and takes a few minutes, held as a live conversation with an AI. I read what comes back and reply with whether a multi-agent build, or a simpler workflow automation, fits what you're trying to solve.

Sources

1. Nicholas Carlini, Anthropic, "Building a C compiler with a team of parallel Claudes" (February 5, 2026) - https://www.anthropic.com/engineering/building-c-compiler - 16 instances of Claude Opus 4.6 building a Rust-based C compiler over nearly 2,000 sessions across two weeks; the lock-file scheme via current_tasks/; "Every agent would hit the same bug, fix that bug, and then overwrite each other's changes"; the GCC-reference test harness that isolated the kernel-compile failure to specific files.
2. Harvey, "Building an Agent for Complex Document Drafting and Editing" (March 24, 2026) - https://www.harvey.ai/blog/building-an-agent-for-complex-document-drafting-and-editing - the isolate-then-reconcile architecture, sub-agents editing private copies with conflicts surfaced to an orchestrator agent, and the measured 40% edit-accept-rate increase and 70% increase in queries per weekly active user against the prior architecture.