Several agents, one repository: ownership rules from real incidents

👥 What goes wrong

One agent on a repository behaves like one careful colleague. Several agents behave like several colleagues editing the same document at the same time with no names on it. Three things happen. They overwrite each other. A commit picks up someone else's half-finished change. And nobody can say afterwards who made a change, so nobody can fix the cause.

📅 Two incidents

On 21 September 2026 an agent wrote a stale copy of a shared control file over a fresh one. The file held the registry of running initiatives. It lost fifteen keys and three pipeline entries, including a reference to an accepted architecture decision.

On 26 September 2026 two agents edited the same temporary worktree at the same time. A commit by one of them would have captured the other's unfinished changes. The second agent also changed the owner of the folder, which broke the first one's test run.

📐 The rules we wrote

1. One worktree per agent. Each agent creates its own folder named after itself and the task, and writes a small owner file in it: agent, process id, time, task. If you find an owner file that is not yours, stop and tell a person.
2. Explicit paths only. Add files by name. Never use "add all", because the shared tree always holds changes that are not yours.
3. Control files are edited one record at a time. Re-read the file immediately before writing. If your tool cannot make a point edit, return the proposed text to the owner instead of writing the file.
4. Every initiative has an owner. The owner implements it. Others propose changes in a report.
5. Finish with a commit. A change left uncommitted in the shared tree when the task ends is a defect: nobody will accept it, someone else's commit may capture it, or it will be lost.

🧪 A test for shrinking files

The 21 September loss could have been caught by a cheap test. Ours compares the control files in the working tree with the committed version and fails when a record that existed in the commit has disappeared. The failure message starts with a fixed word so that it is easy to search for. The test file holds 4 tests and runs in the nightly gate.

🛠️ Practice: set it up in one hour

1. Create a worktree per agent with a script that also writes the owner file.
2. Make "add all" fail by a wrapper or a pre-commit check that lists staged paths and asks for each to be named in the task.
3. Choose the three files that control your system: a registry, a pipeline list, a configuration. Write them down.
4. Write a test that loads each from the commit and from the tree, and fails when a key or record is gone.
5. Add an owner field to each initiative.
6. Add a rule: the task is not finished until the commit and the push are done.

✅ Check yourself

• Start two agents on two tasks. Their folders are different and each holds an owner file.
• Delete a record from a control file and run the test. It fails and names the record.
• Try to stage everything. The check stops you and lists what it saw.
• At the end of a task, git status in the shared tree shows nothing of yours.

🚧 When this does NOT work

• Merge conflicts remain. Separate worktrees move the conflict to the merge. The owner rule is what keeps it small.
• Generated files. Files that every agent regenerates will always conflict. Keep them out of git or serialise them.
• Disk and build cost. Each worktree needs space and a build. Use shallow setups for light tasks.
• Agents that ignore the instructions. A rule in a file is not enforcement. Put the important ones into checks.
• Human edits. People who write into the shared tree break the model. Give them a worktree too.

📊 Evidence

➡️ Next

Learn how to split work between agents in Splitting work across agents, and when not to, and how to hand work over with criteria in Spec-driven development.

Sources

• Splitting work across agents, and when not to: swarm design.
• Spec-driven development with existing task packets: handover with criteria.
• AGENTS.md and rules files: where the rules live.
• An AI usage policy and register a small team can enforce: ownership in the register.