고정 파이프라인과 적응형 분해

When a task is too big for a single prompt, you decompose it. There are two fundamental strategies, and choosing the right one is a core architecture skill.

• Fixed pipeline (prompt chaining): you hard-code a known sequence of steps. Step 1 feeds Step 2 feeds Step 3.
• Adaptive decomposition: the model decides what to do next based on what it discovers, looping until the goal is met.

The rule of thumb: fixed pipelines for known sequential steps; adaptive for open-ended investigations. This lesson makes that decision precise.

A fixed pipeline is just prompt chaining: you orchestrate a deterministic sequence in your own code. You know the steps in advance, so you wire them up explicitly. Each call does one focused job, and its output becomes the next call's input.

Because you control the order, the flow is predictable, debuggable, and cheap to reason about. There is no model-driven branching about what to do next — only the work inside each step.

Reach for a fixed pipeline when the work has a stable, known shape:

• The steps are the same every run (extract, then validate, then format).
• Order matters and rarely changes.
• You want predictable cost, latency, and easy debugging.
• Each stage has a clear, narrow responsibility.

Classic example: structured data extraction. Extract fields, then run a validation/retry pass, then attach provenance. You always do those three things, in that order — so chain them.

Adaptive decomposition hands the planning to the model. You give it tools and a goal; it inspects results and chooses the next action. This is the agentic loop: send a request, inspect the stop_reason, and if it's tool_use, run the tools, append results to history, and repeat until end_turn.

You cannot pre-wire the path because you don't know it in advance — it depends on what each step reveals.

Choose adaptive decomposition for open-ended investigations where the path can't be known ahead of time:

• Debugging from a vague symptom — you grep, read, then grep usages based on what you find.
• Multi-source research where follow-up queries depend on earlier answers.
• Customer support where the next action depends on what a lookup returns.

Here the branching IS the work. A rigid pipeline would either miss paths or explode into unmaintainable conditionals.

The single most common adaptive-loop mistake on the exam: ending the loop by scanning the model's text for words like "done" or "finished." Don't. Decisions are model-driven; terminate on the API stop_reason.

The loop ends when stop_reason is end_turn. While it's tool_use, you keep going. An iteration cap is a safety net only — never the primary stop mechanism. Reserve hard-coded control for guarantees, not for deciding when the work is conceptually complete.

Real systems mix both. The outer flow is often a fixed pipeline, but one stage may be an adaptive agentic loop. You get the predictability of chaining at the macro level and flexibility where you genuinely need it.

Example: an extraction pipeline whose middle stage is an adaptive "resolve ambiguities" agent that may call lookup tools an unknown number of times — wrapped by a deterministic validate-and-format stage before and after.

Decomposition isn't only about pipelines vs loops — it's also about how you split a task to protect the model's attention. Multi-file code review is the canonical case.

A single pass over many files dilutes attention and misses both local bugs and integration issues. The fix is a deliberate decomposition: a per-file local pass first, then a separate cross-file integration pass. Two focused passes beat one unfocused pass.

In a hub-and-spoke multi-agent system, the coordinator decomposes the goal, delegates to subagents, then aggregates. This is adaptive decomposition at the orchestration layer — the coordinator decides how to split based on the request.

Critical: subagents do not inherit the coordinator's conversation history. Every subagent prompt must carry its full context explicitly. Multiple Task calls in one response run in parallel — useful when sub-problems are independent.

Adaptive work often spans sessions. Claude Code gives you --resume <name> to continue a named session and fork_session to branch from a shared point and explore alternatives in parallel.

But beware: resumed tool results can be stale if the codebase changed since. Sometimes a fresh session seeded with a structured summary beats resuming — you get current state plus the distilled context, without dragging outdated tool output along.

Before you build, ask:

• Do I know the steps in advance, in a fixed order? -> fixed pipeline / prompt chaining.
• Does the next step depend on what earlier steps reveal? -> adaptive agentic loop.
• Mostly fixed with one uncertain stage? -> hybrid: chain the outer flow, embed an adaptive loop.
• Reviewing many files? -> decompose into per-file then cross-file passes.

And always: terminate adaptive loops on stop_reason, with iteration caps only as a safety net.

A scenario-based decision on choosing a decomposition strategy.

Key takeaways:

• Fixed pipeline (prompt chaining) for known, ordered steps — predictable, debuggable, cheap.
• Adaptive decomposition for open-ended investigations where the next step depends on what you discover.
• Hybrid is common: a fixed outer flow with an adaptive stage embedded.
• Always terminate adaptive loops on stop_reason (end_turn); iteration caps are a safety net, never the primary stop. Never parse text for "done."
• For multi-file review, decompose into a per-file pass then a separate cross-file pass.
• Subagents don't inherit history — pass context explicitly. Resume sessions carefully; a fresh session with a structured summary can beat stale resumed tool results.