The Frontier · Part I

Orchestration

One agent hits a ceiling: the work outgrows its window, runs one step at a time, and cannot reliably check its own output. This part teaches you to run fleets of agents in parallel and stay in command of the run.

The outcome

You can split a job across many agents, run the right pattern, make the fleet verify itself, hold the cost, and supervise the whole run from one page.

Who this is for

Builders already shipping AI in production, for whom running one agent at a time has stopped being enough.

What you’ll walk out with

You arrive withYou leave with

Fleets built for showDecide when a fleet earns its cost
Evenings spent hand-mergingSplit work so agents never collide
Accidental barriers, wasted waitsChoose the right run pattern
All the checking left on youMake the fleet check its own work
Bills found after the runCap the cost before it runs away
Oversight in name onlySupervise more agents than you can read

Start with chapter one The Orchestration Plan · fillable PDF

A real incident

Even the team that built the system watched a fleet of agents run out of command, and the chapters next door are how you keep yours in it.

01 / 09

A real incident

Anthropic's own research agents spawned 50 subagents for a single simple query, then sent them scouring the web for sources that did not exist.

The engineers caught it and rebuilt the coordination. The model doing the work was Claude, capable and unchanged; what failed was every decision about how the fleet was scoped, split, and bounded.

Anthropic Engineering, 2025, 'How we built our multi-agent research system'

02 / 09

What happened

Given vague instructions, the subagents worked hard on the wrong things.

ANTHROPIC ENGINEERING BLOG

spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources

The model was fine; the run was not.

The instructions were short enough that subagents misread the task. One explored the 2021 automotive chip crisis while two others duplicated each other on the 2025 supply-chain question, each unable to see what the others were doing.

03 / 09

What actually failed

The model produced fine work; the decisions wrapped around the fleet did not.

No contract per agent. Instructions were vague enough that subagents misread the task and duplicated each other's work.

No scope test. A simple query still triggered dozens of agents, when one would have answered it.

No cost bound. Nothing capped a run that used roughly fifteen times the tokens of a single chat.

A stronger model would not have prevented any of this, because the gap was never in the model.

04 / 09

The pattern

Parallelism multiplies cost as fast as it multiplies work.

15x

the tokens a multi-agent run burns versus a single chat

subagents spawned for one simple query before the fix

A fleet's bill scales with tokens times agents, so an ungoverned run can cost far more than the single agent it replaced, with nothing better to show for it.

Anthropic Engineering, 2025

05 / 09

The one idea

Running many agents is a command problem, not a model problem: a fleet only helps if you stay in command of the run.

The failures show up at the joints, in how the work is split, ordered, checked, and paid for, not inside any single agent.

06 / 09

What this part builds

Each move turns a loose swarm into a fleet you can command.

Decomposition

A three-clause contract per work item, so two agents never write to the same file.

Patterns

Pick fan-out, pipeline, judge panel, or orchestrator-worker to fit the actual work.

Verification

Writer-verifier pairs that refute the work and hand back a clean artifact.

Economics

Cap tokens times agents, tier the models, and batch what can wait.

07 / 09

The objection worth answering

"Just use one strong agent and skip the coordination mess entirely."

One agent hits a real ceiling. The work outgrows its context window, it runs one step at a time, and it cannot reliably check its own output. Some jobs are simply too big for one session, and no single model removes that limit.

The mess in the incident did not come from parallelism itself. It came from parallelism nobody governed, with no contracts, no scope test, and no cost cap. The fix is command, not retreat, and that is what these chapters build.

08 / 09

What actually fixes it

Each gap in the incident maps to a move you can build in.

Vague, overlapping tasksDecomposition

→ Write a three-clause contract per work item, so no two agents touch the same file.

Wrong coordinationOrchestration patterns

→ Match the run to fan-out, pipeline, judge panel, or orchestrator-worker before you launch.

No self-checkFleet verification

→ Pair every writer with a verifier that refutes the output before it counts.

Runaway billFleet economics

→ Cap tokens times agents up front, tier the models, and queue what can wait.

Every joint that broke in the incident has a chapter that closes it.

09 / 09

From story to part

Every gap in this incident is a chapter ahead.

Eight chapters take a job too big for one session and let you split it into contracts, run the right pattern, make the fleet verify itself, hold the cost, and supervise the whole run, ending in one reusable page: the Orchestration Plan.

Start with chapter one →

↑ The Builder's Stack The Frontier map →