Chapter D1.2 settled whether to split a task and where the context boundaries are. This chapter asks a different question about the same task: once it is cut into pieces, is the set of pieces fixed in advance, or decided at runtime? That is the pipeline-versus-adaptive choice, and getting it wrong is expensive in opposite directions — an Evaluate-level judgment the exam probes with concrete tasks.

Do I know this already? Diagnostic

Answer these confidently and you can skim ahead to Exam essentials; if any is shaky, read closely — each is developed below.

What distinguishes a sequential pipeline from adaptive decomposition — and when is each structure set?
Why can’t open-ended research be reduced to a hardcoded pipeline?
Roughly what token multiplier does an adaptive multi-agent flow cost versus a single agent, and does parallelism buy speed or thoroughness?
Name the over-decomposition failure mode and the heuristic that guards against it.
Which structure is usually programmatically enforced, and why?

Check your answers

A sequential pipeline’s steps are hardcoded and fixed at design time; in adaptive decomposition an orchestrator decides the shape at runtime, scaling subtasks to the input.
Open-ended research is “inherently dynamic and path-dependent” — step N+1 depends on what step N discovered, so no design-time sequence can capture it.
Roughly 3–10× more tokens than a single agent (about 15× a chat), and parallelism buys thoroughness, not speed — coordination plus the slowest subagent often make wall-clock slower.
Over-decomposition — e.g. “spawning 50 subagents for simple queries” — guarded by the effort-scaling heuristic (1 agent / 2–4 subagents / 10+, sized to complexity).
The sequential pipeline — your code drives the fixed sequence, because nothing about the structure needs to be decided live.

Two shapes of a decomposed task

A decomposed task takes one of two structural shapes, distinguished by when the structure is determined.

The difference is not how many agents run but who decides the shape and when: the author, in advance, or the orchestrator, on the fly. Each is right for a different kind of task.

When the path can’t be hardcoded → adaptive

Some work resists a fixed pipeline by its nature. Anthropic’s research system is explicit about why: “Research work involves open-ended problems where it’s very difficult to predict the required steps in advance. You can’t hardcode a fixed path for exploring complex topics, as the process is inherently dynamic and path-dependent.” [Official] How we built our multi-agent research system · Anthropic (2025)T1-official original When step N+1 depends on what step N discovered, no design-time sequence can capture it.

Adaptive systems handle this by scaling effort to the input. The research system embeds the heuristic directly in its lead-agent prompt: “Simple fact-finding requires just 1 agent with 3-10 tool calls, direct comparisons might need 2-4 subagents with 10-15 calls each, and complex research might use more than 10 subagents with clearly divided responsibilities.” [Official] How we built our multi-agent research system · Anthropic (2025)T1-official original

When the path is predictable → pipeline

The opposite case is just as common and far cheaper to run. When a task’s steps are known, repeatable, and the same every time, a fixed sequential pipeline is the right structure: it is deterministic, auditable, and predictable in cost, and it asks the orchestrator to make no runtime judgment at all. A pipeline is typically programmatically enforced (D1.4) — your code drives the fixed sequence — precisely because nothing about the structure needs to be decided live. Reaching for adaptivity here is wasted capability: you pay for an orchestrator’s deliberation to re-derive a structure you already knew at design time.

The cost you are choosing

“Cheaper” and “more expensive” are not hand-waving — the choice has a price tag, and the exam expects the number. An adaptive multi-agent flow “typically use[s] 3-10x more tokens than single-agent approaches for equivalent tasks,” [Official] Building multi-agent systems: When and how to use them · Anthropic (2026)T1-official original and on the absolute scale, “multi-agent systems use about 15× more tokens than chats.” [Official] How we built our multi-agent research system · Anthropic (2025)T1-official original What that spend buys is thoroughness, not speed — parallel subagents explore a larger space, but coordination plus the slowest subagent often make the wall-clock slower, not faster. [Official] Building multi-agent systems: When and how to use them · Anthropic (2026)T1-official original

The same data, two shapes Worked example

Two tasks that look superficially similar decompose oppositely:

Pipeline — summarize 200 support tickets to a fixed JSON shape. The steps are identical for every ticket (read → extract fields → emit JSON), so the structure is fixed at design time. Cost is bounded: 200 × (one fixed path). You fan the same path across all 200 tickets — parallel throughput, not adaptive structure — and your code enforces it (D1.4). No orchestrator judgment, no token-multiplier surprise.

Adaptive — “find out whether any competitor shipped feature X; go as deep as the question needs.” Depth is unknowable up front and each finding changes what to look at next (path-dependent), so a lead agent sizes the decomposition at runtime via the ladder: a quick check might be 1 agent, 3–10 calls; a real comparison 2–4 subagents; a deep dive 10+. The capability to branch is the point — but it costs 3–10× the tokens of a single agent, and the guard is the effort ladder so it doesn’t spawn ten subagents to confirm an obvious “no.”

Same input domain (text about a topic); opposite structures, because one path is predictable and one is not.

The failure mode at each extreme

Both shapes fail, in opposite ways, when matched to the wrong task.

Over-decomposition is the adaptive failure: an orchestrator that misjudges effort produces absurd structures. Among the research system’s documented early failures was “spawning 50 subagents for simple queries” — capability with no judgment behind it, multiplying token cost for nothing. [Official] How we built our multi-agent research system · Anthropic (2025)T1-official original The effort-scaling heuristic exists to mitigate exactly this.

Rigid pipelining is the inverse: forcing a fixed sequence onto path-dependent work, which then cannot adapt when a step surfaces something the design didn’t anticipate. And a pipeline cut by role rather than context is the telephone-game anti-pattern of D1.2 — sequential phases of one coupled task, losing fidelity at every handoff. [Official] Building multi-agent systems: When and how to use them · Anthropic (2026)T1-official original

Choosing the structure

The Evaluate-level call comes down to predictability. Choose a sequential pipeline when the steps are knowable in advance and you value determinism, auditability, and bounded cost. Choose adaptive decomposition when the task is open-ended and path-dependent and that capability is worth the orchestrator overhead and the 3–10× variable cost. Either way, the orchestrator (or the author) must size effort to the task — adaptivity does not excuse you from judgment; it relocates it to runtime.

Practice

Exercise solutions

Solution ↑ Exercise

(a) Sequential pipeline. (b) Adaptive. (a) The steps are known and identical for every ticket, and the output is a fixed shape — nothing to decide at runtime, so a deterministic pipeline wins on cost, auditability, and predictability. (You fan the same fixed path across 200 tickets — parallel throughput, not adaptive structure.) (b) The depth is unknowable up front and each finding changes what to look at next — “you can’t hardcode a fixed path… inherently dynamic and path-dependent” — so the orchestrator must scale the decomposition to what it discovers. On (b) guard against over-decomposition (don’t spawn ten subagents to confirm an obvious “no” — size effort via the 1 / 2–4 / 10+ ladder), and accept that you are paying roughly 3–10× the tokens of a single agent for the thoroughness.

Solution ↑ Exercise

Hardcode a sequential pipeline when the steps are knowable and identical in advance (predictable, repeatable); decompose adaptively only when the task is open-ended and path-dependent — when step N+1 depends on what step N discovers, so no design-time sequence can capture it.

Solution ↑ Exercise

They are paying roughly 3–10× the tokens of a single-agent pipeline (about 15× a chat). That spend buys thoroughness — a larger explored space — not speed (coordination plus the slowest subagent often make it slower in wall-clock). It is wasted here because a fixed, predictable nightly job has nothing to decide at runtime: the orchestrator’s judgment is re-deriving a structure already known at design time, so you pay the multiplier for capability the task never needed. A deterministic pipeline is the correct, bounded-cost shape.

Exam essentials

Two shapes, distinguished by when the structure is set: a sequential pipeline is fixed at design time; adaptive decomposition is decided at runtime by the orchestrator.
Adaptive when the path can’t be hardcoded — open-ended, path-dependent work where step N+1 depends on step N. Scale effort to the input (the 1 / 2–4 / 10+ heuristic).
Pipeline when steps are predictable — deterministic, auditable, bounded cost, usually programmatically enforced (D1.4). Adaptivity here is wasted.
Adaptive costs 3–10× the tokens of a single agent (≈15× a chat), and buys thoroughness, not speed. A pipeline’s cost is bounded; an adaptive flow’s is variable and can spike.
Two opposite failure modes: over-decomposition (“50 subagents for a simple query”) for adaptive; rigid/role-based pipelining (the telephone game) for fixed.
Choosing turns on predictability — and either way the orchestrator must size effort to the task. (Whether to split = D1.2; how to enforce = D1.4.)