Run one coding agent in a repository and the failure modes are familiar: a wrong edit, a missed test, a misread requirement. Run ten of them at once — same repository, same checkout, same afternoon — and a different class of failure appears. Not wrong work. Mutually invisible work.
Over a two-week window in one of Coven’s active repositories, we ran as many as nine concurrent familiar sessions against a single checkout. This dispatch is what broke, what caught it, and what didn’t. The short version: git is very good at catching the cheapest failure and structurally incapable of catching the expensive ones.
The cauldron is shared state#
A git checkout is not just files. It is one working tree, one index, one HEAD, one stash stack. Every tool in the standard development loop — status, add, commit, pull — quietly assumes those belong to a single author.
Ten sessions in one checkout all make that assumption simultaneously. Each one is locally correct. The composition is not.
When two sessions touch the same surface, the outcome lands in one of three buckets, and they are not equally expensive.
Bucket one: duplicate work — cheap, and git catches it#
Two sessions independently write the same fix. Git detects identical patches at merge or push time; the collision surfaces as a conflict or an “already up to date.” Worst case, the same cleanup commit lands twice on a branch under the same name — wasted review cycles, no broken behavior.
Worth noting: when we searched the history for duplicates, most candidates turned out to be rebase-replay artifacts — the same logical commit (same author date, different commit date and parent) landing on main twice through two merge resolutions. That is the same patch counted twice, not duplicate authorship. Genuine duplicate work was rare. The folk fear about parallel agents — “they’ll all do the same thing” — was, in this window, mostly unfounded.
Bucket two: orphaned work — expensive, and nothing catches it#
The canonical case, reconstructable entirely from commit history:
23:20 PR lands — polishes sessions-view.tsx (+286 lines, including tests)
23:58 parallel session's refactor drops the SessionsView fallback
00:30 sessions-view.tsx, its CSS, and the polish test deleted (-2,132 lines)
Session A polished a surface. Session B was, at the same moment, mid-refactor toward deleting that surface. A’s work merged, built clean, passed every test — and was gone from main in about seventy minutes.
Here is the structural point, and it is the heart of this dispatch. Duplicate work lives in the codebase: two diffs against the same lines collide at commit time, and git refuses to silently lose data. Orphaned work lives in intent: “I am about to delete this surface” exists only in Session B’s running context. It is never in the file tree, never in the index, never in git status. There is no point in the standard developer loop where impending removal becomes visible to anyone else.
That means orphaned-work prevention cannot be retrofitted through git or CI. The signal has to live somewhere both sessions check before committing to a direction. (This is interpretation, but we believe it is load-bearing: it tells you which tools can and cannot solve the problem.)
Neither session did anything wrong. Both did locally valid work. The waste is not redundancy — it is misallocation.
Bucket three: state races — corrupting, and git participates#
The first two buckets are about outputs colliding. The third is about the shared checkout itself, and it is the nastiest, because git is not the detector here — git is the mechanism.
Two incidents from a single day, with five and nine live sessions respectively:
The amend clobber. Several sessions shared one branch on the primary checkout. One session ran git commit --amend to touch up “its” latest commit. But HEAD had moved — the latest commit belonged to a different session. The amend rewrote another familiar’s work. (The clean escape, for the record, was a squash-merge of the surviving state — not an attempted rebase on a checkout that was still being raced.)
The autostash swallow. One session had carefully staged a specific set of changes. A second session’s git pull --autostash began, stashing and popping the shared working tree mid-operation — while a third session ran git add -A && git commit && git push. The staged work was absorbed into the third session’s commit. The first session’s index simply emptied under its feet. No error. No conflict. The work shipped — under someone else’s commit, mixed into someone else’s change.
The lesson compresses well: on a shared checkout, the index and working tree are not yours. Any operation that assumes exclusive ownership of mutable git state — amend, rebase, reset --hard, autostash, add -A — is a race waiting for its second participant.
What actually helps#
Ordered by cost, from field experience rather than theory.
1. Worktree-per-session as the default, not the exception. Each session gets its own git worktree on its own branch. This dissolves bucket three entirely — no shared index, no shared HEAD, nothing to race. It does not prevent orphaning, but it surfaces divergence at the PR moment instead of the silent-deletion moment: a freshly opened PR diffed against current main is the first place a parallel session’s removal shows up while there is still time to react. git worktree list is also, today, one of the only places where “another session is working on branch X” is visible at all.
2. Defensive habits that assume a hostile checkout. Push every commit promptly — an unpushed commit on a shared checkout is one amend away from nonexistence. Commit by explicit pathspec, never add -A, when the index may contain another session’s files. Never amend or rebase on a checkout you do not exclusively own.
3. Sentinel assertions for removed surfaces. When deleting a surface, leave a negative-import test asserting it stays gone. A future session that resurrects the file gets an immediate, mechanical signal — even if it never reads the history. This catches re-orphaning, not the first orphaning, but it converts tribal knowledge into a failing test.
4. A surface-claim file (proposed, not yet built). A gitignored claims.json: “session X started work touching surfaces Y, Z, with this intent,” checked before starting and before committing. Cheap, useful, fragile — nothing forces sessions to write claims, and stale claims must expire. It is the cheapest mechanism that addresses intent rather than output, which is exactly the layer where orphaning lives. We have not shipped it; we are stating the design, not results.
5. The human as the bridge — which is the current state, named honestly. Today, the only entity with cross-session visibility is the person running the sessions. “I’m about to delete SessionsView,” surfaced to the user, gives them the chance to say “wait — another session is polishing that.” This works, and it does not scale, and both things are true.
What this is really about#
The cauldron metaphor earns its keep here. Many familiars stirring one cauldron is not a model-capability problem — every session in every incident above was doing competent, locally-correct work. It is a coordination protocol problem, and it sits squarely in the harness layer: the scaffolding between the model and the world.
Human teams solved the analogous problem long ago, mostly out-of-band — standups, Slack channels, “I’m touching auth this week.” Concurrent agent sessions have none of that by default. They have git, and git’s contract is narrower than people assume: it protects committed bytes from silent loss. It does not protect intent, and on a shared checkout it does not even fully protect the index.
Open questions we are still sitting with:
- Is the claims file worth prototyping, or does worktree-as-default cover enough of the gap on its own?
- Does this taxonomy generalize beyond coding agents? The same orphaning failure exists for two humans pair-programming on one checkout — but humans usually have a side channel. What is the familiar’s side channel?
- The user is currently the cross-session bridge by hand. Do any of these mechanisms actually make that job smaller, or do they just relocate the bookkeeping?
What we can say with confidence: the expensive failures were the quiet ones. Everything that made noise — conflicts, rejected pushes — was cheap. If you are scaling out concurrent agent sessions and your monitoring is “did git complain,” you are measuring the bucket that was never the problem.
