The moment more than one AI agent works on a single repository, this happens sooner or later: agent A needs to commit, but the working tree holds agent B’s unfinished changes. Now what? Commit everything together? “Clean up” someone else’s work? Wait indefinitely?
For us this was not a hypothesis. It happened — and the incident produced an enforceable standard. This is a case study about multi-agent collaboration being a governance problem, not a prompting problem.
The incident
July 2026, the Yggnet Labs development server. Agent Cowork (working remotely, with no direct access to the server’s file system) had a larger model configuration change sitting in the repository — uncommitted. A second agent received a priority task from the owner: add image support to the campaign system, including a database migration. But that migration would interleave with the first agent’s unfinished migrations. Work stalled.
The classic answer — “they should just be careful” — does not work. Agents rotate across sessions, context evaporates between them, and “being careful” is not a mechanism.
What we built
1. Commit-before-handoff. A binding rule: before handing work to another agent (or ending a session with work in progress), an agent commits its state to its own working branch. Unfinished work is no reason to block others.
2. Workspace claims. Before larger work, an agent locks files or directories through a shared service. Colliding with someone else’s claim returns an error naming the holder — and gets resolved by a message, not by overwriting. The records are append-only: an audit trail of who held what, and when.
3. A pre-commit guard. A git hook that simply blocks any commit touching someone else’s claimed area. An emergency override exists — but it is logged, with a mandatory justification. Discipline is enforced by the machine, not by the agent’s good will.
4. A git worktree per agent. Two agents working concurrently = each in its own worktree on its own branch. Verified by a live experiment: two agents, interleaved commits, no mixed-up work in progress.
5. Delegated commit. An agent without file system access formally delegates the commit to an agent that has it — with the owner’s consent and an audit trail. That is exactly how the original incident was resolved.
The failure mode we found along the way
While verifying the worktree setup, we discovered that the pre-commit guard silently disabled itself in a linked worktree — repository detection failed and the hook “passed” without checking anything. A silent failure of a safeguard is worse than no safeguard, because you trust it. The fix (detection via the git common dir) landed the same day, and blocking from within a worktree has been part of the test suite ever since.
This, incidentally, is why GALDUR insists that guardrails be tested as rigorously as production code: a safeguard nobody has verified is fiction.
What to take away
- A multi-agent team needs explicit workspace ownership — the same thing human teams have in the form of code ownership and branch protection.
- Rules must be machine-enforceable (a hook, a lock, an audit log), not an appeal to caution.
- Exceptions should not be forbidden — they should be expensive and visible: a logged override with a justification.
- An agent without access is not a second-class citizen — it needs a formal delegation path with an audit trail.
This case study is one of the conditions GALDUR set for itself for version v1.0 (“at least 3 case studies”). The methodology is open — documentation, templates, community.
Comments
…