Best tools for running multiple AI coding agents on one repo

What is the best tool for multiple AI coding agents?

There isn't one: pick by the shape of the work, not by the tool. If your agents work on provably disjoint code, git worktrees win: free, native, zero new dependency. If you have two careful agents and no rush, sequential (run one, let it finish, run the next) beats everything for simplicity. If agents share one working tree with blurred task boundaries, especially across different vendors, a coordination layer like Befall is what stops silent collisions. If you want one brain delegating to workers, an orchestrator-subagent setup fits, but that's one agent's plan, not peers negotiating. The rest of this page is the detail behind each, honestly, including where Befall is the wrong answer.

Context for the honesty: I built Befall by running three agents (Claude Code, Codex CLI, and Cursor) in a single Befall room on this repo. So the failure modes below aren't hypotheticals. They're the ones I hit, in the order I hit them.

When are git worktrees the best choice?

Best when the work is genuinely disjoint and you can prove it up front. A worktree gives each agent its own checkout on its own branch, separate directories over one object store. Agent A edits in ../repo-agent-a, agent B in ../repo-agent-b, and neither ever sees a half-written file from the other. That solves the most physical problem, two processes writing the same file on disk, for free, with tooling you already have.

git worktree add ../repo-agent-a -b feat/agent-a
git worktree add ../repo-agent-b -b feat/agent-b
# each agent runs in its own directory, its own branch

Where it breaks: worktrees isolate, they don't coordinate. The collision doesn't disappear. It moves to merge time. When both branches touch src/auth/, each agent proceeds confidently and the conflict lands on the human at the end, fully formed, with two plausible histories to reconcile. Worktrees also assume you can partition the work cleanly before you start; with agents that plan as they go, the "disjoint" assumption is often wrong by the second file.

Pick worktrees if: you split tasks by hand, the boundaries are real (one agent on /docs, another on an isolated feature module), and you're comfortable resolving the occasional merge. The full breakdown lives in the worktrees comparison.

When is running agents one at a time the best choice?

Best for two careful agents when you aren't racing the clock. Sequential is the approach nobody markets because there's nothing to sell: run one agent, let it finish and commit, then run the next on top of a clean tree. No isolation layer, no coordination protocol, no new tool. The second agent sees the first's work as committed reality, not as a moving target.

Where it breaks: throughput. You've serialized the thing you spun up multiple agents to parallelize. If a single agent's task takes 40 minutes, three of them cost you two hours wall-clock even though nothing about the work required waiting. It also quietly degrades: "one at a time" turns into two overlapping when you get impatient, and now you have collisions with none of the machinery to catch them.

Pick sequential if: you have two agents, the tasks are small, and correctness matters more than wall-clock time. Honestly, for a lot of solo work this is the right default: reach for something heavier only when the serialization actually hurts.

When is a coordination layer like Befall the best choice?

Best when agents share one working tree, task boundaries blur, and the agents come from different vendors. This is the case worktrees and sequential both handle badly: several agents editing the same checkout, planning as they go, where "who owns src/api/ right now" changes minute to minute. Befall adds a shared room per repo (roster state, task handoffs, advisory path locks, messages, and conflict alerts) so an agent can announce intent and get told no, someone holds that before it edits, not after.

The mechanism is advisory locks, first-writer-wins. An agent requests paths; Befall computes overlap against every other agent's active locks; any overlap returns a 409 with the conflicting paths named. Locks carry a TTL and auto-release when an agent goes offline, so a crashed agent can't wedge the room. It's advisory: Befall never switches your branch and never blocks a write at the filesystem. What an agent gets is an answer to “who holds this?” before it edits — worth exactly as much as the agents asking.

The privacy model is the part I'd want to know before installing anything. Source code and diffs never leave. What does: paths, branch names, commit SHAs, dirty-path lists, claims, task titles and free-text descriptions, and the messages agents write. The last two are content you author and they are stored — paste a function into a handoff note and the note is uploaded with the function in it. Realtime broadcasts carry an empty payload; the envelope still routes (room, topic, event kind, actor, timestamp), and subscribers re-fetch the change through the authenticated REST API. So the answer to "I'm not shipping my codebase to a third party" is that the codebase stays put and the file names do not; see the security page for the field-by-field list.

Where it breaks / where it's the wrong tool: if your agents work on genuinely disjoint code, Befall is overhead you don't need. The claims never overlap, so you're running a coordinator to coordinate nothing. (Separate worktrees on their own don't settle it: each worktree is a checkout Befall can track, and two of them editing the same file still collide at merge.) And it's advisory: an agent that ignores the protocol and edits anyway isn't stopped, only flagged. Befall assumes cooperating agents, not adversarial ones. It also adds a daemon and a network dependency; for a single agent it's pure ceremony.

Pick a coordination layer if: multiple agents, shared working tree, blurred boundaries, mixed vendors. The exact setup in the Claude Code + Codex + Cursor guide. It's free for 1 room and 2 concurrent agents; founding plans are $15/mo (list $29) when you outgrow that.

When is an orchestrator + subagents the best choice?

Best when you want one plan and one accountable brain, not peers negotiating. An orchestrator setup (Claude Code subagents, a lead agent spawning workers) has one agent hold the plan and delegate slices to short-lived subagents whose context it controls. The partitioning problem does not go away, but it moves: the workers don't choose what to touch, the orchestrator does, and it is the orchestrator's plan that has to keep them apart.

Where it breaks: it's one vendor and one context budget. Subagents can't bring a second model's strengths (you can't make a Claude subagent be Codex), and everything routes through the orchestrator's window, which becomes the bottleneck on large work. It's also fragile to the orchestrator's own mistakes. A bad plan propagates to every worker, because there's no peer to push back. Compare this split, one brain vs independent peers, against the multiple-instance case in multiple Claude Code agents on one repo.

Pick orchestrator + subagents if: the work decomposes cleanly from the top, you're happy inside one vendor, and you want a single agent to own the outcome. It composes with Befall rather than competing. The orchestrator can be one member of a room alongside independent agents from other vendors.

What does a real coordination refusal look like?

A refusal is a payload, not a stack trace. A Codex agent claims packages/shared/src/path-overlap.ts; a Claude agent already holds packages/shared/src/**. The two globs share a file, so the second claim comes back 409. Written out — Befall ships no CLI that prints these lines, so this is the shape of the response and not a captured session:

vs_lock_acquire  agent=codex
  paths: ["packages/shared/src/path-overlap.ts"]
  -> 409 DENIED  conflicts:
       held by claude · "packages/shared/src/**"
       both claims cover packages/shared/src/path-overlap.ts
  event: lock.denied

Every field there is one the agent can act on: who holds it, what they hold, and the concrete file that made the two claims collide. What happens next is the agent's decision — take other work, or message the holder. Befall recorded a refusal; it did not stop anyone from opening the file.

Why is deciding whether two agents overlap hard?

Because path overlap is glob intersection, and globs have edge cases that a naive implementation gets wrong. The core of any coordination layer is one question: do the paths agent A wants intersect the paths agent B holds? It sounds like string matching. It isn't. A lock on src/** has to overlap a request for src/api/route.ts, and a lock on src/**/api has to match src/api, which means ** must match zero directories as well as many.

The first implementation got that wrong: it treated ** as "one or more path segments," so src/**/api failed to match src/api and two agents were told they didn't conflict when they did. There's now a regression test that pins exactly this, ** matching the empty span, so the bug can't come back:

// packages/shared/src/path-overlap.ts: pinned by regression test
pathsOverlap("src/**",       "src/api/route.ts") === true
pathsOverlap("src/**/api",   "src/api")          === true   // ** matches ZERO dirs
pathsOverlap("src/**/api",   "src/lib/api")      === true   // ** matches many
pathsOverlap("src/api/**",   "src/web/route.ts") === false

This is why "just diff the file lists" isn't enough, and why the overlap algorithm is kept pure and heavily tested. When Befall told Codex no in the log above, it was this function, with the zero-directory case correct, that made the call.

How do I choose between them?

Answer four questions in order and the choice falls out.

Is the work provably disjoint before you start?
   yes -> git worktrees. Done.
   no  -> keep going.

Do you actually need parallel throughput?
   no  -> sequential (one agent, finish, commit, next). Done.
   yes -> keep going.

One vendor, top-down decomposable plan?
   yes -> orchestrator + subagents. Done.
   no  -> keep going.

Multiple agents, shared tree, blurred boundaries, mixed vendors?
   yes -> coordination layer (Befall).

The categories also stack. Worktrees plus Befall is a real combination: isolate the filesystem and coordinate intent, so neither agent sees the other's half-written file and each one can ask who holds a path first. Each worktree is a checkout in the room. An orchestrator can be one member of a Befall room. The point is to match the tool to the shape of the work, not to run the heaviest option everywhere.

Honest verdict

Most people running two agents should start with worktrees or sequential, and most people will be fine there. That's the un-salesy truth: if your work partitions cleanly, you don't need a coordination layer, and if you have two careful agents and time, sequential is the least machinery for the job. Reach for those first.

Befall earns its place in a specific spot: multiple agents sharing a checkout, task boundaries that blur as the agents plan, and agents from different vendors that can't share a subagent hierarchy. That's exactly the case where worktrees defer the collision to merge time and sequential throws away the parallelism. In that spot, advisory locks with a correct overlap algorithm, plus a privacy model where source code and diffs never leave the machine, is the difference between agents that collide silently and agents that get told no in time to re-plan. It's free for 1 room and 2 concurrent agents; go from there only if the work demands it.