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 type | Pattern | Why |
|---|---|---|
| Multi-file code review against set criteria | Fixed chain: per-file passes, then an integration pass | Both kinds of analysis are known before reading the code |
| Draft, review against criteria, then refine (self-correction) | Fixed chain with a gate between stages | The stages do not depend on what the draft says |
| Extraction or transformation into a defined output | Fixed chain | Input varies; the steps and the output contract do not |
| Debugging an unfamiliar or intermittent failure | Adaptive | Each finding decides the next question |
| Multi-source research, or a multi-file change of unknown scope | Adaptive, orchestrator-workers | The subtasks cannot be predicted before exploring |
| Adding tests to a legacy codebase | Adaptive inside fixed stages: map, prioritize, plan, verify | The 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 jsonvalidates 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
Every pull request in a CI pipeline must be reviewed for the same three concerns — input validation, logging of sensitive data and public API compatibility. The team must keep each concern’s output in the log, so that a wrong verdict can be traced to the step that produced it. Which decomposition fits?
A team must explain why a production-only notification is sometimes sent twice. Nobody knows yet whether the cause lies in the queue consumer, a retry policy or a delivery adapter. Which way of structuring the investigation fits this uncertainty?
An engineer proposes splitting a request into three separate API calls — draft, critique, refine — to get better answers from a current Claude model. In which situation does the explicit chain earn its extra calls?
A team must add a feature to an unfamiliar service. The work must always pass through exploration, planning, implementation and verification, but which files need changing is unknown until exploration. Which structure fits?
References
- Anthropic, Building effective agents
- Anthropic, Prompting best practices
- Anthropic, How we built our multi-agent research system
- Anthropic, CLI reference
- Anthropic, How Claude Code works
- Anthropic, Best practices for Claude Code
- Anthropic, Permission modes
- Anthropic, Tools reference