Multiple AI agents on one repo
Several AI agents can work in one repository once something stops them writing over each other. Murmell keeps a board of file reservations. An agent claims the paths it is about to touch, and the board records one holder per path and refuses everyone else until the holder releases it.
The agents run on a cloud machine in one project directory, not in a worktree each, so an agent reads what its peers wrote a minute ago rather than at merge time.
What goes wrong without a board
Give three agents the same checkout and they overwrite each other inside a minute. Last write wins, silently. It surfaces later as a test that broke for no visible reason, or as a function that came back from the dead after somebody deleted it.
Nobody fixes this by asking the models to be careful. Two agents can both be careful and still collide, because neither of them can see what the other is holding.
Claim, write, release
An agent asks for the paths it needs. If nobody holds them, it gets them and writes. When it is done it releases them and the next agent waiting gets its turn.
The rule lives on the server. It is not a line in a system prompt, so an agent that ignores it is refused rather than trusted. A write that collides anyway is snapshotted before it lands, and a watcher attributes every write back to whoever made it.
The write that collides is caught at the board, not on disk.
What two agents did with it
We watched two agents work on our own runs, without telling them the board existed as anything other than a tool they could call. They called it 1.8 times per turn. Two writes out of two were covered by a claim. Twice, an agent refused to overwrite a file a peer was holding, and we had to insist before it would.
Measured on our own two-agent runs. A small sample and our own observation, not a benchmark.
The usual alternative
The common answer is one worktree per agent and a merge at the end. It works, and no agent sees another’s work until the merge, so two of them can spend an hour writing the same helper twice and a third can build against an interface that changed underneath it.
One directory removes that. The cost is that somebody has to arbitrate the writes, which is what the board is for.
Who watches the agents
Every window on the multi-agent canvas is a real terminal running Claude Code, Codex, or another CLI agent. Everyone on the link sees all of them live. Reservations show up as they are taken, so a person can see which agent is holding the file they were about to ask about. Read our step-by-step guide to running several agents, explore the technical mechanics of file reservations, or check multiplayer coding with AI agents for the collaboration model.
Straight answers
Do I need a git worktree per agent?
It is what most guides recommend, and it works: each agent gets its own checkout with its own index, so nothing can collide. The cost is one merge per copy, and a conflict you find at the end. On a shared directory with claims there is nothing to merge, because two live versions never existed.
Can several AI agents work in the same repository?
Yes, once something stops them writing over each other. Murmell keeps a board of file reservations: an agent claims the paths it is about to touch, and the board records one holder per path and refuses everyone else until the holder releases it.
What goes wrong without a board?
Give three agents the same checkout and they overwrite each other inside a minute. Last write wins, silently, and it surfaces later as a test that broke for no visible reason or a function that came back from the dead after somebody deleted it.
How does a file reservation work?
An agent asks for the paths it needs. If nobody holds them, it gets them and writes; when it is done it releases them and the next agent waiting gets its turn. The rule lives on the server, so an agent that ignores it is refused rather than trusted.