One agent is fast. Three agents on one repository should be three times faster. Instead they overwrite each other's work, act on views of the code that went stale minutes ago, and hand off references that no longer point anywhere.
You split a task three ways. Agent A refactors session handling in auth.py. Agent B adds audit logging to the same module. Agent C reviews what they produce. All three start at 10:02.
Nothing crashed. Each agent did its job correctly against the code it could see. B never saw A's edit, because it wasn't committed. C never saw either, because its index was built before both. The result is a confident, reviewed, merged change that's missing half the work.
"3/3 tasks complete. Changes reviewed and approved."
Every agent reads files, keeps them in context and writes back later. Between the read and the write, the world moves. The tools agents use can't tell them: plain text search only sees what's on disk right now, git only sees what's been committed, and each agent's index is a snapshot from when it was built. These are the same failure modes teams report as soon as they run more than one agent: overwritten files, stale views of the codebase, and agents tripping over each other's in-progress work (Augment Code, MindStudio).
Three agents load the same file at the same moment.
Uncommitted edits are invisible to every other agent, and private indexes freeze at build time.
The final writer erases what came before. The reviewer approves a snapshot that's already gone.
We ran the tools agents rely on today through the same multi-agent tasks. Plain text search is correct and cheap but blind to other agents. Indexes and language servers give a view, but go stale or multiply per agent. Here is every fleet row, not just the flattering ones.
| Task | Text search | File reads | git | Language server | Embeddings | ARR |
|---|---|---|---|---|---|---|
| Coordination | ||||||
| See another agent's uncommitted edits, right now | ✕ | ✕ | ~files only | ~ | ✕stale | ✓ |
| One shared view, built once | ✕ | ✕ | ~commits only | ~ | ✓ | ✓ |
| Hand a verifiable result to another agent | ~path:line, goes stale | ~ | ~ | ~ | ✕ | ✓refs with hash |
| Stay correct under concurrent edits | ✓ | ✓ | ✓ | ~ | ✕ | ✓ |
| Running cost at scale | ||||||
| Many queries at once, without waiting | ✓ | ✓ | ✓ | ~ | ✓ | ~queries take turns |
| Memory across many agents | ✓ | ✓ | ✓ | ✕one server per agent | ~ | ✓still one service |
| Setup cost | ✓ | ✓ | ✓ | per agent | ~shared | ✓paid once, shared |
✓ handles it · ~ partially · ✕ can't. Internal benchmark, not independently verified. Text search and file reads are cheap and always current, but they can't see other agents' in-progress work. ARR is the only column that handles every coordination task. Its one partial result is that, in this setup, simultaneous queries take turns.
Two agents edit the same file from the same starting copy. The second write silently deletes the first, because uncommitted edits are invisible.
Every agent sees the others' uncommitted edits live, as they happen.
An agent edits from what it read at the start. Another agent changed that file since, so the patch lands on the wrong lines or undoes their work.
An agent is told its earlier read is no longer valid before it writes.
Each agent indexes the repo or starts its own language server, paying the cost again. Those private views drift apart and go stale as files change.
One shared view, built once, kept correct while files change, and used by every agent from a single service.
Agent A passes auth.py:142 to Agent B. By the time B reads it, the file has shifted and line 142 is something else.
Every reference carries a fingerprint of the exact code, so the receiving agent can confirm it's unchanged.
Give each agent its own worktree and they can't overwrite each other. They also can't see each other, so the overlap surfaces as a merge conflict after both have finished.
Agents see where their work overlaps while they're still working, not at merge time.
The standard fix is one git worktree per agent: separate working directories, shared history. It works. Agents stop erasing each other's files. But it trades a silent overwrite for a loud merge conflict at the end, after every agent has finished and the context of why each change was made is gone.
ARR takes the opposite approach: instead of hiding agents from each other, it gives them one shared, current view of the code, including each other's work in progress. It runs under the agents and orchestrator you already use.
These results are from our own internal benchmark and aren't independently verified. The table includes the one place ARR is only partial: in this shared setup, simultaneous queries take turns rather than running fully in parallel. For a single agent working alone, most of these tasks don't apply, which is why they're marked separately in our wider results.
Anything missing is work one agent erased without either of them knowing. That's the part ARR makes visible.
We're opening ARR to a small group of teams running more than one agent. Tell us how you run them today and we'll be in touch when your place is ready. No payment required.
More in ARUKAS Field Notes:
Your AI is answering from an old document
When legal AI gets the clause wrong
Chunking breaks meaning
Why AI coding agents break things three files away
Which version of the policy did your AI just apply?
AI citation errors start before the AI writes anything
Duplicate files, duplicate totals: where AI reconciliation goes wrong
What AI prior-art search doesn't tell you it missed
How ARR works →