Befall vs git worktrees for parallel AI coding agents

What do git worktrees actually solve?

A git worktree gives each agent its own checkout of the repository on its own branch — separate working directories backed by one object store. That solves a real problem: two processes writing the same file on disk. Agent A edits in ../repo-agent-a, agent B in ../repo-agent-b, and neither ever sees a half-written file from the other. If your agents work on genuinely disjoint tasks — one refactors the docs while another builds an isolated feature — worktrees plus disciplined task-splitting can be all you need, for free, with tooling you already have.

Where do worktrees break down with AI agents?

Worktrees isolate; they do not coordinate. The collision doesn't disappear — it moves to merge time. When both agents touch src/auth/ on their own branches, each proceeds confidently, and what lands on the human at the end is a classic git merge conflict — two AI-authored versions of the same logic waiting to be untangled by hand. Three things make this worse with agents than with human teammates: agents don't glance at each other's branches before starting; they re-implement work another agent just finished (there is no shared task board in git); and nothing tells agent C that agents A and B are even running. Every worktree also multiplies ceremony — one checkout, one branch, one context per agent, torn down and re-created per task.

What does a coordination layer do differently?

Befall keeps every agent in one shared working tree and prevents the overlap before an edit happens. An agent claims a path glob; a conflicting claim is refused at claim time. This is a real log line from our own room, the first day we ran three agents on this codebase:

$ agent A → lock  apps/web/app/api/**        ✓ held
$ agent B → lock  apps/web/app/api/route.ts  ✗ refused
  → conflicts with A · ttl 8m

Agent B never wrote a byte into that path — it picked non-overlapping work instead. Locks are advisory with first-writer-wins semantics and auto-release on TTL (default 30 minutes) or when an agent goes offline. And when an agent skips the protocol entirely, the daemon's git heartbeats still stream dirty-path lists, so the room flags the overlap anyway — all the way to a PR check that says which agent holds locks touching the PR. Only metadata leaves the machine: paths, branches, SHAs, locks — never source code or diffs.

Why is path overlap harder than it looks?

"Just check if the paths overlap" hides real semantics. One edge case from our own test suite: src/**/api must match src/api — **/ has to match zero directories as well as many. Our first implementation got that wrong and the regression test now pins it. Boundary cases matter too: src/api and src/apiary must not collide on a prefix check. All of Befall's conflict detection routes through one pure, heavily tested glob-intersection module — the kind of thing you don't want every team re-deriving in a shell script.

Can you use worktrees and Befall together?

Yes — they solve different layers. Some teams keep worktrees for hard filesystem isolation and still run a Befall room across them: the shared task board stops two agents from doing the same job twice, handoffs move work between agents with context, and dirty-path heartbeats give early warning that two branches are about to fight in the same directory — before the merge, not during it.

Honest verdict — who wins when?

Worktrees win when tasks are provably disjoint, you run at most two agents, and you're happy resolving the occasional merge yourself: zero cost, zero new tools. A coordination layer wins when agents share one working tree, task boundaries blur, more than two agents run at once, or several humans each bring their own agents to one repo — the cases where "isolate and merge later" quietly becomes "untangle it by hand every afternoon." Befall is free for 1 room and 2 agents, so the experiment costs nothing: here's the full setup guide.