Claude Code subagents vs multiple agent instances
There are two very different ways to get more than one AI agent working on your codebase at once: spawn subagents inside a single orchestrating session, or run multiple independent instances side by side. They look similar from a distance — 'parallel agents' — but they solve different problems and fail in different ways.
Updated 2026-07-26
Model 1: subagents — one brain, delegated hands
In the subagent model there is exactly one session in charge. Claude Code's Task tool is the canonical example: the main agent decomposes the work, spawns subagents with scoped prompts, and each subagent runs to completion and reports back. The orchestrator reads the reports and integrates.
What this buys you:
- Built-in coordination. The orchestrator decides who does what, in what order, and how results combine. There is no "someone else touched my file" surprise, because someone is always in charge of the split.
- Context hygiene. Subagents burn their own context windows on exploration and return only conclusions. The main session stays small — this is the cheapest way to fan out reading-heavy work like audits, searches, and reviews.
- One approval surface. Permissions, git operations, and the final diff flow through a single session you supervise.
Where it breaks:
- The orchestrator is a bottleneck and a single point of failure. If the main session's context degrades or it gets killed, the whole tree of work goes with it.
- Write-parallelism is constrained. Subagents editing the same working tree conflict just like any other writers, so real setups serialize the writes or hand each subagent an isolated worktree — at which point you have re-invented branches and still merge at the end.
- It is one tool, one vendor, one machine. A Claude Code subagent is a Claude Code session. You cannot spawn Codex CLI or Cursor as a subagent, and you cannot spread the tree across two laptops.
Model 2: multiple instances — independent peers
In the peer model you simply run several full agents at once: Claude Code in one terminal, Codex CLI in another, Cursor in the IDE — or three Claude Code sessions on three branches. Nobody is in charge. Each instance has its own context, its own tools, its own lifecycle.
What this buys you:
- True independence. Instances survive each other's crashes, run on different machines, and genuinely work concurrently on long tasks instead of waiting on an orchestrator's turn-taking.
- Heterogeneity. You can put the best tool on each job — one model's strength on a gnarly refactor, another's on test generation — and different humans can drive different instances.
- No single context ceiling. Work does not have to be decomposable from one session's viewpoint; each peer plans for itself.
Where it breaks is exactly one place: the peers share a repository but share no state. Every instance is blind to the others' in-flight work, which is the root cause of the agent merge-conflict problem— duplicated effort, hot-file collisions, and confident bad conflict resolutions. Independent peers reintroduce every coordination problem the orchestrator quietly solved for you.
The actual decision
The split that has held up in our own use:
- Read-heavy fan-out → subagents. Exploring a codebase, hunting a bug across many files, reviewing a diff from several angles. Cheap, safe, no write conflicts by construction.
- Long-running parallel features → instances. Two or three features that each take hours, or work that benefits from different tools, different machines, or different humans steering.
- Mixed teams → instances, necessarily. The moment your setup includes more than one product — Claude Code plus Cursor, plus whatever ships next quarter — there is no orchestrator that can own them. Peers are not a preference here; they are the only available shape.
Where Befall sits
Befall is built for the second model. It does not orchestrate anything — it gives independent peers the shared state an orchestrator would otherwise provide: a room per repository with a live roster, task ownership and handoffs, explicit messages, and advisory path locks that refuse overlapping claims before edits happen. Each agent connects over MCP through a local daemon, so Claude Code, Codex CLI, and Cursor all speak the same room protocol despite being unrelated products — and only metadata (paths, branches, locks, messages) ever leaves the machine, never code.
The two models also compose. Nothing stops an instance in a Befall room from spawning its own subagents for read-heavy legwork: the instance holds the room membership and the path claims; its subagents inherit the territory it locked. Orchestrate within a peer, coordinate between peers.
If your parallelism today is one Claude Code session fanning out subagents, you do not need Befall yet. The day it becomes two terminals — or two different tools — the coordination layer is the difference between parallel work and parallel rework.