Subagent Orchestration Patterns for Coding

A subagent is a child agent with its own fresh context window, dispatched by an orchestrating agent (or a script) to do one job and return a result. Orchestration is how single-agent coding workflows scale past the two walls every practitioner hits: the context wall (one window cannot hold a whole investigation) and the serial wall (one agent does one thing at a time). This page catalogs the patterns that actually pay for themselves; the general theory is in MultiAgentOrchestration.

Why Subagents: Isolation First, Parallelism Second

The under-appreciated benefit is context isolation, not speed. A subagent that greps through fifty files burns its own window on the exploration and returns three sentences; the orchestrator keeps the conclusion without the pollution. Even purely serial subagent use — one delegated deep-dive at a time — materially extends how long the main thread stays sharp. Parallelism is the bonus on top: independent subagents fan out simultaneously, bounded mainly by how independent the tasks really are.

The discipline that makes both work: the subagent's report is the product. Prompt subagents to return distilled, structured answers (findings, file:line references, verdicts) — never transcripts of what they looked at. Schema-validated structured output, where the harness supports it, beats free-text reports.

Role Decomposition: Planner / Implementer / Reviewer

The canonical division of labor mirrors a small engineering team:

Planner — a strong model decomposes the goal into independently verifiable tasks with acceptance criteria (this is SpecDrivenDevelopment worn as an agent role).
Implementers — one subagent per task, each given a complete, self-contained brief. The brief quality is the result quality: a subagent starts cold, knows nothing you didn't tell it, and cannot ask mid-flight follow-ups.
Reviewer(s) — separate subagents check the work against the criteria. Separation matters: an agent reviewing its own implementation shares its own blind spots; a fresh context has none of the implementer's motivated reasoning.

The Core Patterns

Fan-out / fan-in — map a work list (files to migrate, modules to audit, findings to check) over N parallel subagents, then aggregate. The workhorse pattern; scales to hundreds of items with a concurrency cap.
Pipeline — multi-stage processing (find → verify → fix) where each item flows through stages independently, with no barrier between stages: item A can be in stage 3 while item B is still in stage 1. Prefer this over staged barriers — a barrier makes every fast item wait for the slowest.
Judge panel — generate N independent attempts from deliberately different angles, score them with parallel judges, synthesize from the winner. Wins over one-attempt-iterated when the solution space is wide (API design, architecture choices).
Adversarial verification — for each claimed finding or completed task, dispatch skeptic subagents explicitly prompted to refute it; only claims that survive ship. This is the single most effective known filter for the plausible-but-wrong failure mode — see VerificationLoopsForAgenticCoding.
Loop-until-dry — for unknown-size discovery (bug hunts, dead-code sweeps), keep dispatching finder rounds until K consecutive rounds surface nothing new. Fixed counts ("find 10 bugs") systematically miss the tail.
Completeness critic — a final subagent asks only "what's missing?" — an angle not searched, a claim not verified. Its findings become the next round's work list.

Deterministic Orchestration: Control Flow in Code

The 2026 refinement — an application of FlowEngineering — is separating control flow from judgment. Loops, fan-outs, aggregation, and retry policy are deterministic and belong in a script; only the per-item reasoning belongs in a model. Mature harnesses expose exactly this: a workflow script that calls agent(prompt) inside ordinary loops and pipelines. The shape:

items   = discover_work_list()            # deterministic
results = parallel(items, i => agent(brief(i)))   # judgment, fanned out
verified = parallel(results, r => agent(refute(r)))  # adversarial pass
report(verified.filter(survived))          # deterministic

The orchestrating model deciding on the fly when to spawn what is flexible but non-reproducible; a workflow script does the same fan-out identically every run, can be resumed, and can be reviewed like any other code.

Model Tiering

Orchestration is where per-task model routing becomes mechanical policy instead of per-prompt judgment: frontier-tier for planning, the adversarial verify stage, and final synthesis; mid-tier for implementation against existing patterns and first-pass review; small-tier for mechanical stages with a complete spec (boilerplate, format conversion, single-file edits). Since the fan-out stages are where the volume is, tiering routinely cuts orchestration cost by 3–5× with no observable quality loss — and when unsure, step one tier up rather than let a cheap model botch integration work.

When Orchestration Is Wasted Compute

The task fits comfortably in one context window — a single agent with a good brief beats a committee.
The subtasks are not actually independent — agents block on each other's outputs and you've built a slow pipeline with extra steps.
The aggregation is the hard part — ten mediocre parallel drafts don't merge into one good one; some work is irreducibly serial.
You can't verify the pieces — fan-out without a verification stage just parallelizes the production of unchecked claims.