Befall vs Claude Code agent teams
Claude Code can now run several of its own sessions as a team, with a shared task list and direct messaging between them. The obvious question is whether that makes a coordination layer redundant. It does not, and the reason is written into Anthropic's own best-practices section rather than inferred from outside.
Updated 2026-09-01
Short answer
Agent teams spawns and coordinates parallel Claude Code sessions. It does not arbitrate file edits: its documentation tells you to partition files by hand so teammates do not overwrite each other. A coordination layer answers that instruction with a shared register instead of a convention — advisory, so it refuses a claim rather than blocking a write — and it applies to every agent, not only Claude Code ones.
Read from Anthropic’s agent teams documentation on 2026-08-14. The feature is experimental and moving quickly, so the specifics are a snapshot. The structural point below is not the kind of thing a patch release changes.
What agent teams actually is
One Claude Code session becomes a lead and spawns others as teammates. Each teammate is a full independent session with its own context window, they share a task list, and they message each other directly instead of reporting only to the lead. It is disabled by default behind CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, the team is scoped to a single session, and the state lives in JSON files under ~/.claude/teams/.
This is a genuinely good feature and it is free and built in. If you were reaching for a coordination layer in order to run several agents at once, agent teams does that better than anything you would assemble yourself, and this page is not an argument against using it.
The file locking that is not file locking
The claim you will see repeated is that agent teams has file locking, so the collision problem is handled. We believed it too, from two separate research passes, until we read the page. The phrase appears once, and it is about claiming a task. Task claiming uses a lock so two teammates cannot claim the same item off the shared list simultaneously. That is a correct and necessary thing to do, and it protects the queue.
Nothing in the feature sits between a teammate and the file it decides to edit. Two teammates that both conclude they need src/api/routes.ts will both open it, both edit their own copy, and the second write wins. The task list will show two completed tasks.
Anthropic writes the problem statement
The best-practices section of that page has a heading called Avoid file conflicts, and under it a sentence that says “Two teammates editing the same file leads to overwrites.” The recommended fix is to break the work up so each teammate owns a different set of files. Elsewhere the same page recommends teams for new modules where teammates can each own a piece without stepping on each other, and steers you away from teams entirely for same-file edits.
That advice is honest and it is correct. It is also the entire premise of this category. Partitioning by hand works exactly as well as your guess about what the work will touch, and the guess is made before the work starts. A refactor that turns out to need a shared type, a bug fix that turns out to live one layer down, a test file two teammates both need to extend: these are the cases where the partition you drew at the start stops describing the work you are doing.
They are not alternatives
Agent teams answers how to spawn and direct parallel work. A coordination layer answers what happens when two pieces of parallel work reach for the same file. Running both is coherent, and it is the setup this was written from: the lead decides who does what, and each session claims the paths it is about to touch, so a session that asks for a glob someone already holds is told at claim time instead of finding out from git. The claims are advisory. Befall refuses a request; it does not sit between a session and the filesystem, and a session that never asks is never refused.
There is one thing agent teams structurally cannot cover. A teammate is a Claude Code instance. If you also run Codex CLI, or a Cursor window, or a colleague brings their own agent to the same repository, none of them are in the team, cannot see its task list, and cannot be seen by it. The shared state is local JSON scoped to one session on one machine. For a single person running only Claude Code that costs nothing. It is the whole problem the moment it is not.
Does agent teams lock files?
Not for your files. The documentation mentions file locking once, and it is about the shared task list: claiming a task uses a lock so two teammates cannot claim the same one at the same time. That protects the queue, not the working tree. Nothing stops two teammates opening the same source file and writing over each other.
What does it do about file conflicts instead?
Anthropic's own answer is to partition the work. Its best-practices section says two teammates editing the same file leads to overwrites, and tells you to break the work so each teammate owns a different set of files. That is a real fix and for a lot of tasks it is the right one. It just puts the partitioning on you, before you know what the work will touch.
Can you use agent teams and Befall together?
Yes, and it is the setup this is written from. Agent teams decides how many Claude Code sessions to run and what each one is for. Befall is what those sessions claim paths through, alongside a Codex CLI or a Cursor window that agent teams cannot see at all. They answer different questions: one is how to spawn parallel work, the other is what happens when two pieces of parallel work reach for one file.
Can a teammate be Codex CLI or Cursor?
No. A teammate is a Claude Code instance. Codex CLI, Cursor, or a colleague's agent are outside the team entirely, and the task list and mailbox live in local JSON files under your home directory scoped to one session. If everything you run is Claude Code on one machine, that is not a limitation you will feel.