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 or blocks a write at the filesystem — but agents that respect it stop colliding.

The privacy model is the part I'd want to know before installing anything. Only metadata leaves the machine: paths, branch names, commit SHAs, dirty-path lists, locks, tasks, and explicit messages. Source code and diffs never leave. Realtime broadcasts are signal-only — the payload is an empty object; subscribers re-fetch through the authenticated REST API — so even the push channel carries no content. If your objection to a coordination service is "I'm not shipping my codebase to a third party," the answer is you aren't; see the security page for the field-by-field list.

Where it breaks / where it's the wrong tool: if your agents work in true isolation (separate worktrees, disjoint modules), Befall is overhead you don't need — the locks never conflict, so you're running a coordinator to coordinate nothing. 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. There's no collision problem because there's no independent decision-making: the workers don't choose what to touch, the orchestrator does.

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?

Here's the actual thing, from day one of building Befall inside a Befall room. Three agents were live. The Codex agent tried to claim a lock on paths that overlapped what the Claude agent already held. Befall refused it — this is the log, verbatim:

[befall] vs_lock_acquire  agent=codex-cli
  paths: ["packages/shared/src/path-overlap.ts"]
  -> DENIED (409)  conflicts:
       claude-code holds "packages/shared/src/**"  (ttl 240s)
  event: lock.denied
[befall] codex-cli re-planned: took packages/db/src/schema.ts instead

Without the coordination layer, both agents would have edited path-overlap.ts — the single most load-bearing file in the codebase — on the same working tree, and I'd have found out at merge or, worse, at test time. Instead Codex got a 409 with the holder and the conflicting glob named, and re-planned onto a file nobody held. No human in the loop. That refusal is the whole product in one line.

Why is "do these 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 you get no half-written files and no surprise merge conflicts. 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, one shared working tree, 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 metadata-only privacy model where 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.