The Agent Ladder: Fan Out by Model Tier

Grinding a large task through one model burns tokens on work that model shouldn't be doing. A top-tier session that greps a hundred files and drafts a first pass in its own context pays premium rates for work a cheaper model does just as well, and drags every tool call's output into the context the top model needs for the hard decisions.

The fix: decompose the task into tiered, parallel subagent waves that climb a model ladder instead of working it inline.

Seats on the ladder

Four seats, each with a distinct job.

• Haiku gathers and does the mechanical work: lookups, searches, doc reads, fact extraction, and bulk edits from an exact recipe.
• Sonnet builds and validates. It distills and checks Haiku's output, then writes the implementation, the refactors, and the tests, anything that produces working code.
• Opus reviews and judges: independent review, architecture calls, anything security-sensitive.
• Top tier orchestrates. It decomposes the task, writes the briefs, reconciles conflicts across slices, and synthesizes the final result.

Model names are floors, not ceilings. An "Opus" seat means "the top tier this pattern budgets for judgment," and a frontier session (Fable-class or above) fills it correctly absent an explicit pin. Whatever tier leads, the routing underneath doesn't change.

Cost and context isolation

The routing optimizes cost and context isolation, not raw capability. Keeping legwork off the top-tier context is the point: a subagent works in its own window and reports back a distilled result. Run a search inline and the context fills with a hundred grep hits to reason over; delegate it to Haiku and the orchestrator gets one paragraph.

Anthropic's research write-up backs this up, directionally: an Opus lead with Sonnet subagents beat a solo Opus session by 90.2% on research-shaped tasks, at roughly 15x the tokens of a single chat turn (a multi-agent systems post puts a more general setup at 3-10x). Treat both as directional, not a promise for today's models. Fan out buys quality past a real threshold, at real token cost, per a threshold Anthropic names directly: three or more independent pieces of work, or ten or more files to read. Research spanning multiple sources, or review that's earned a fresh pass, also clears the bar. Any one trigger is enough; don't wait for all four, or trust a gut call on whether a task "feels big enough."

Gather, execute, review, synthesize

Not every task needs every wave. A pure research question skips execute; a mechanical edit with an exact spec can go straight to a Haiku executor. When a task decomposes into independent slices, the shape looks like this:

• Gather, run by Haiku, collects the facts before anyone writes anything: codebase survey, doc lookup, inventory.
• Execute, on Sonnet, produces code or artifacts, or distills and validates a gather report into a conclusion.
• Review is Opus's job: a fresh, adversarial pass, mandatory for security-sensitive work, worth it for high-stakes changes, skippable for cheap lookups.
• Synthesis falls to the top tier, which reconciles conflicts, triages findings, and decides what ships.

Slices don't wait on each other by default. A slice whose gather wave finished can start executing while a sibling is still gathering. Hold a global barrier only when a wave needs every slice's output at once, such as deduping findings across slices.

Briefing a cold colleague

Every subagent starts blind: no memory of this conversation, no sense of why the work matters. A brief has to stand on its own.

1. Goal: what to produce, in a sentence or two.
2. Why: the larger task this slice feeds. Knowing the reason produces better work than knowing only the instruction.
3. Context: file paths, repo facts, and prior-wave findings the subagent needs but can't see.
4. Scope: what to touch and what to leave alone, since models follow instructions literally.
5. Deliverable: exactly what to report back, down to the shape of the answer.

The caching consequence is easy to miss: subagents don't share the parent's prompt cache, so each builds its own from a cold start. Point five agents at the same long doc and it gets paid for five times over. Distill shared context into a short digest and inline it instead.

When to reach for it

Fan-out earns its keep exactly when a task both lacks a spec and decomposes into independent slices.

• A single hand-off with no pipeline is one job for one agent, which is what delegate is for.
• Work already governed by a spec's task list belongs to orchestrate: each task is a stream with dependencies already mapped, better served by one subagent per stream than by re-decomposing into ad-hoc waves.
• Genuinely ad-hoc, no-spec work that decomposes into independent slices is the fan-out lane, gated by the bright-line triggers above.

Caps that keep fan-out honest

The triggers say when fanning out pays. They don't say when it stops paying, and with a lead model that delegates readily, that's the binding constraint. Four caps, each one a way a fan-out costs more than it returns.

1. Never delegate self-verification. The frontier models check and correct their own work unprompted, so a subagent spawned to re-read output the lead just produced is pure overhead. Writer-verifier across agents is a different thing and still the right shape: a fresh reviewer who didn't write the code catches what the author can't.
2. Use one agent when one agent covers it.
3. Nothing you could finish in a handful of tool calls. Dispatch has a floor. In my own research skill, a brief of one or two questions against a source the session can already reach now skips the fan-out entirely and gets answered inline: same citations, same written artifact, no wave. The verification still runs even when the dispatch gets skipped.
4. Nothing tightly coupled. Slices must own disjoint files. Two agents editing the same file in parallel produce a merge conflict instead of speed.

The fourth cap is the one that changed how I decompose. It bounds fan-out by coupling, independently of the count triggers: three slices that all rewrite one module are still one slice's worth of work, and no amount of independent-piece-counting makes them parallel. If the decomposition can't hand each slice its own files, the work belongs in one context window.

The same logic kills the relay: a chain where each step needs the previous step's full output is one job passed hand to hand, paying the dispatch cost at every link while degrading the context at each hop.

Dogfooding: porting the skill to itself

The clearest test of the pattern was using it on itself: porting a personal skill for this workflow into a shared, reviewed version for a team plugin. Haiku gatherers mapped every sibling skill so the port's boundaries would be exact instead of guessed. A top-tier agent, briefed with that map distilled down, authored the improved skill file. A fresh Opus reviewer, blind to how the draft got written, checked it adversarially. The orchestrating session reconciled the findings, redispatched the real ones, and rejected the rest with a stated reason.

It's the same pattern this post describes, applied to the skill that names it.

Mechanical edges

Past the four caps, the pattern has a few mechanical edges: cap a wave around six concurrent agents, since quality drops past that; run one review wave and one redispatch per slice, since anything needing more is spec territory; and never let a subagent spawn its own subagents.

None of this removes judgment from the process; it moves the judgment to fewer, more expensive decisions. The orchestrator still makes every hard call; it just stops making the cheap ones. Before the next fan-out, the check now runs caps first, disjoint files and a real dispatch cost, and only then the count triggers.