Skip to lesson

AnthropicClaude Certified Architect – Foundations2026-101.6 Design task decomposition strategies for complex workflows

Choose decomposition from what you know

Completed by the knowledge check

Learning objective

Choose fixed prompt chaining for predictable stages versus adaptive decomposition when later subtasks depend on discoveries.

Core idea

Choose the decomposition pattern by asking whether you can name the necessary stages before the first result arrives. A review with established criteria can follow a fixed prompt chain. An investigation whose next question depends on a search result needs adaptive decomposition. Task length alone does not decide between them.

Anthropic describes prompt chaining as successive model calls that consume earlier outputs, with optional programmatic gates between stages. Its orchestrator-workers pattern instead uses a central model to determine subtasks, delegate work, and synthesize results. The distinguishing property is when you determine the work, rather than how many agents participate.

For an architect, this choice decides where workflow control belongs. A fixed chain puts stage order in application code. Adaptive decomposition lets model reasoning select the next evidence-gathering task within the assignment. See 1.1.3 for tool-selection control and 1.2.3 for choosing specialists; this lesson addresses the shape of the work itself.

How it works

Define a fixed chain when stages are known

Consider a review that always checks individual files before checking their interactions. You know both kinds of analysis are required even before reading the patch. Define a local-analysis stage, a handoff gate, and an integration stage. Findings change what the second stage examines, but do not change the existence or purpose of that stage.

Anthropic’s prompt-chaining pattern trades additional latency for focused calls. Each call has a narrower job than a request to perform every kind of review at once. The earlier output becomes an input, so its quality matters: an integration reviewer cannot reliably recover a dependency that a local reviewer omitted from its handoff.

A chain is not automatically a quality upgrade. Anthropic’s prompting best practices state that, with adaptive thinking and subagent orchestration, Claude handles most multistep reasoning internally. Explicit chaining remains useful when you need to inspect intermediate outputs or enforce a specific pipeline structure. Its most common form is self-correction: generate a draft, have Claude review it against criteria, then refine it, each step a separate API call that you can log, evaluate, or branch on.

In a Claude Code pipeline, your script can invoke stages with claude -p and carry their findings forward; see 1.6.2 for the scripted chain, structured handoffs, and coverage gates.

Use adaptive decomposition when evidence creates tasks

An incident investigation starts with a symptom rather than a complete file list. An initial search might locate a cache, a background worker, or a configuration-dependent branch. Each discovery changes which questions matter. Predetermining every worker assignment would either miss those branches or spend effort on unrelated possibilities.

Anthropic’s multi-agent research system is built on the same premise: exploring a complex topic is inherently dynamic and path-dependent, so no fixed path can be written down before the work starts. The orchestrator-workers pattern fits this uncertainty because the orchestrator determines subtasks based on the specific input. A coding task may require changes in files that cannot be predicted before exploration. The input establishes the initial decomposition; findings-driven changes to subsequent actions are documented separately in Claude Code’s agentic loop.

Claude Code also supports adaptation inside one session. Its agentic loop gathers context, acts, and verifies results, choosing subsequent actions from tool feedback. You do not need multiple agents merely because the plan changes. Delegation is useful when a discovered question warrants a separate assignment; the Agent tool supplies that mechanism, as covered in 1.3.2.

Give the adaptive task a stable goal and a concrete completion check. For example, ask Claude to explain a failed transaction using a reproducible test and the responsible call path. The next search can change, while the required explanation remains the same. Without that anchor, open-ended exploration can fill the context without producing a decision.

Combine stable stages with adaptive work inside them

A workflow can use both patterns at different levels. Keep a required sequence of exploration, planning, implementation, and verification, while letting exploration discover the files to inspect. Anthropic’s Claude Code best practices recommend separating exploration and planning from implementation when the approach or codebase is uncertain.

Start exploration with claude --permission-mode plan; see 1.6.3 for plan review, approval, and the source-edit and shell-command boundaries.

The hybrid’s fixed part is the acceptance process. Its adaptive part is the work needed to satisfy that process. A required integration check does not become optional because an investigation found a surprising dependency. Instead, update the check’s inputs to include the discovered relationship.

Key distinctions and trade-offs

Fixed stages versus fixed answers: Prompt chaining fixes the kinds of work and their order. The answers can still vary, and a gate can reject incomplete output. A predictable workflow does not require predictable findings.

Adaptive decomposition versus parallel execution: Dynamic decomposition decides what work exists. Parallel execution decides when independent work runs. You can investigate adaptively and sequentially, or run predetermined file reviews concurrently before a required integration stage.

Workflow complexity versus task complexity: A large, repetitive review may fit a simple chain. A short but ambiguous defect may require adaptive investigation. More agents do not compensate for an inappropriate task boundary.

The core test, whether you can name the stages before the first result arrives, sorts common task types:

Task typePatternWhy
Multi-file code review against set criteriaFixed chain: per-file passes, then an integration passBoth kinds of analysis are known before reading the code
Draft, review against criteria, then refine (self-correction)Fixed chain with a gate between stagesThe stages do not depend on what the draft says
Extraction or transformation into a defined outputFixed chainInput varies; the steps and the output contract do not
Debugging an unfamiliar or intermittent failureAdaptiveEach finding decides the next question
Multi-source research, or a multi-file change of unknown scopeAdaptive, orchestrator-workersThe subtasks cannot be predicted before exploring
Adding tests to a legacy codebaseAdaptive inside fixed stages: map, prioritize, plan, verifyThe order of work holds; the targets emerge from the code

The chain is easier to inspect because each stage has a known responsibility, but it adds calls and can pass omissions downstream. Adaptive work can discover missing requirements, but needs a clear scope and verification signal to avoid unbounded exploration. Choose the least elaborate pattern that addresses the uncertainty you actually have.

Architecture / decision scenario

A developer-productivity service accepts two requests. The first asks it to review a supplied patch for local correctness and cross-file compatibility. The second asks why a production-only notification sometimes appears twice.

For the patch, the service invokes focused local reviews with claude -p, checks that the handoffs cover the patch, and supplies them to the integration pass. Both stages are known in advance. A discovered caller gives the integration pass something to inspect; it does not require replacing the whole workflow with an autonomous investigation.

For duplicate notifications, the service begins an investigation that can revise its tasks. A search identifies a retrying queue consumer; reading that code reveals a separate delivery adapter. Claude follows that relationship before proposing a fix and a regression check. The discovered call path determines the next subtask, so a fixed list of file reviews would be premature.

Both requests end with evidence against their original criteria. The difference is whether you can specify the necessary intermediate work before seeing the evidence.

Common exam traps

  • Selecting adaptive decomposition solely because a patch contains many files.
  • Letting a review that runs on every pull request in CI choose its own stages, so similar patches are checked differently from run to run.
  • Adding an explicit chain for quality alone when no intermediate output needs inspection and no fixed pipeline is required.
  • Treating a fixed chain as one oversized prompt containing several headings.
  • Confusing dynamic task discovery with running known tasks in parallel.
  • Assuming --output-format json validates the review’s application-specific handoff.
  • Replacing verification with a confident final summary.
  • Treating plan mode as unconditional isolation from shell side effects.

What to remember

Use fixed chains when you know the required stages. Use adaptive decomposition when findings determine the next tasks. Keep the goal and completion checks explicit in either pattern, and combine fixed acceptance stages with adaptive exploration when both are needed.

Knowledge check

References