Split a refactor across five agents and you get your first coordination lesson for free. Two of them open the same module and stomp each other's edits. A third declares the task finished while the other four are still mid-change. A fifth burns its whole context window re-deriving the project layout that the first agent worked out an hour ago. Each agent, on its own, did competent work. The system produced a mess.
The instinct is to reach for a smarter orchestrator — a bigger model on top, more reasoning, a better plan. That's the wrong layer. Coordinating agents is a state-management problem, not an intelligence problem. Agents are stateless between tool calls and amnesiac between sessions; what holds a fleet of them together is the state they write down, not the cleverness of whichever one is in charge.
Two of Anthropic's engineering write-ups make this concrete from opposite directions, and reading them together is more useful than reading either alone.
Breadth and depth are the same problem
One axis is breadth: running many agents at once. Anthropic's multi-agent research system uses an orchestrator-worker shape — a lead agent (Claude Opus 4) spins up three to five subagents (Claude Sonnet 4), each with its own context window and its own tools, exploring different angles in parallel. That parallelism cut research time by up to 90% on complex queries and beat a single-agent Opus 4 setup by 90.2% on their internal research eval.
The other axis is depth: running one line of work across hours or days. Here the problem is that each new session begins with no memory of the last one — closer to shift work than to a single long shift. Different axis, same underlying failure and same fix: the information that coordinates the work has to live outside any single agent's head.
Decomposition is the lead agent's real job
Vague delegation is where parallel setups fail first. Point several subagents at "research the semiconductor shortage" and they all chase the same angle instead of dividing the work. The fix is to give every subagent an explicit objective, an output format, guidance on which tools and sources to use, and — the part that actually does the coordinating — task boundaries that don't overlap.
Effort scales with complexity: a simple fact-find is one agent and a handful of tool calls; a genuinely hard task is 10+ subagents with divided responsibilities. Those non-overlapping slices are the coordination. They're what keep two agents from editing the same file in the first place.
The file system is the message bus
Agents don't chatter to each other. They read and write shared files, and the orchestrator sequences work around them. That substrate is where coordination actually happens. In the long-running case it's three artifacts working together: a progress log, git history, and a structured feature list.
The feature list is the sharp example. It's JSON, and the rules on it are strict:
[
{ "id": 42, "description": "New chat button creates a fresh conversation", "passes": false },
{ "id": 43, "description": "Messages persist across a page reload", "passes": false }
]
Agents may flip passes from false to true — nothing else. Editing a description or deleting an entry is off-limits. That one constraint turns a shared file into a trustworthy channel: no agent can quietly rewrite the definition of done to make its own work look finished, and a fresh context window reads the file and instantly knows what's left.
The artifacts aren't documentation. They're the shared memory a stateless system coordinates through.
Across sessions, the same discipline
The long-running setup splits roles by time. An initializer runs once: it writes an init.sh to boot the dev server, creates the progress file, makes the first git commit, and enumerates the feature list. Every coding session afterward starts cold and follows a fixed boot sequence — confirm the working directory, read the git log and progress file, pick the highest-priority incomplete feature, run init.sh, and verify the app actually works before touching anything new.
The agent never trusts its memory because it has none; it reconstructs state from artifacts every time. That's the same move as the parallel case, rotated from space into time.
Verification is coordination too
A subagent that marks work "done" without checking corrupts shared state for everyone downstream — which is exactly what the immutable feature list exists to prevent. So verification isn't a final gate bolted on at the end; it's part of coordination. In practice the coding agents confirm features end-to-end with browser automation before flipping passes, and those visual checks caught bugs that unit tests missed. The research system runs a separate citation pass after synthesis rather than trusting each subagent's own summary. Judge work in the same optimistic context that produced it and the optimism compounds.
What it costs, and when to pay
None of this is free. The multi-agent research system burns roughly 15x the tokens of a chat turn; even a single agent runs about 4x. Token volume alone explains around 80% of the performance variance on their eval — you are, in large part, paying for coordination. It only earns that back on high-value work that is genuinely parallel and too big for one context window. Execution is synchronous, so the lead waits for each batch of subagents before continuing, and long jobs need durable execution so a stalled agent resumes instead of restarting from zero.
The honest read is that most tasks don't clear this bar. A quick fix or a self-contained feature is cheaper and more reliable as one agent in one session. Reach for a fleet when the work is wide, valuable, and won't fit in a single head.
The takeaway
Before you add another agent, add another artifact. The count of agents is a scaling knob; the shared files are the coordination. Design those first — the boundaries that keep slices from overlapping, the progress log and git history a cold session reads to rebuild context, the one append-only record of "done" that no agent can edit in its own favor. Get them right and parallelism becomes a lever you pull, not a risk you manage.
Sources: How we built our multi-agent research system — Anthropic · Effective harnesses for long-running agents — Anthropic