Task Decomposition
PatternsDefinition
The process of breaking a complex task into smaller, independently executable subtasks that can be assigned to specialized subagents or processed sequentially. Good decomposition creates subtasks with clear boundaries, independent execution, and verifiable outputs.
Example Usage
Decompose 'analyze this codebase for security issues' into subtasks: dependency audit, input validation check, authentication review, secrets scan.
Why It Matters for the CCA-F Exam
Task decomposition appears in both Domain 1 (Agentic Architecture) and Domain 6 (Cost and Performance Optimisation). The exam tests whether you can identify well-formed vs poorly-formed subtasks in a scenario, and whether you connect decomposition quality to routing efficiency. Expect at least one question about the narrow decomposition risk (over-slicing loses context) and one about parallel vs sequential subtask ordering.
In Depth
What Decomposition Really Means
Task decomposition is not just "break a big thing into small things." In the context of Claude-based systems, it means producing subtasks that satisfy three properties:
- Independent execution — subtasks can run (and be verified) in isolation without knowing how other subtasks are progressing.
- Clear I/O contracts — each subtask has an unambiguous input specification and an expected output schema. This is what allows the orchestrator to dispatch subtasks and parse results reliably.
- Verifiable outputs — you can check whether a subtask succeeded without human review at every step.
Subtasks that fail these tests create brittle pipelines that break under real-world inputs.
Decomposition Strategies
| Strategy | When to use | Risk |
|---|---|---|
| Functional decomposition | Tasks with distinct domain boundaries (security audit → dependency check, auth check, secrets scan) | Misses cross-cutting concerns |
| Sequential decomposition | Tasks with strict data dependencies (fetch → parse → summarise) | No parallelism benefit |
| Parallel decomposition | Tasks with independent subtasks (query multiple data sources simultaneously) | Aggregation complexity |
| Adaptive decomposition | Complexity unknown at design time; coordinator decides subtasks dynamically | Harder to test; requires strong coordinator |
See Adaptive vs Fixed Decomposition for a full treatment of when each applies.
The Narrow Decomposition Trap
One of the most common failure modes is over-decomposition: slicing tasks so finely that the subtasks lose necessary context. A subtask asked to "check authentication" with no access to the rest of the codebase cannot produce a meaningful result. Good decomposition ensures each subtask has the context it needs, not just the scope it covers.
The opposite failure — under-decomposition — sends too much to a single subagent, overloading its context window and producing shallow results across a large surface area.
Connecting Decomposition to Routing
Decomposition and model routing are complementary. Once you have identified subtasks, you can route each to the cheapest model capable of handling its specific scope. A security audit might route the dependency check to Haiku (pattern matching) and the architectural flaw analysis to Opus (deep reasoning). The combination of good decomposition and good routing is the primary lever for cost optimisation in agentic systems.
How It Compares
| Approach | Parallelisable | Context per subtask | Output predictability |
|---|---|---|---|
| Monolithic call (no decomposition) | No | Very high | Low |
| Sequential chain | No | Medium | Medium |
| Parallel decomposition | Yes | Low–medium | High |
| Adaptive (coordinator decides) | Conditional | Variable | Medium |
| Hierarchical (nested coordinators) | Conditional | Low per level | High |
Frequently Asked Questions
How do I know if my subtasks are too granular?
A subtask is too granular if it cannot be completed correctly without information that lives outside its own input. For example, a subtask that checks only one function for security issues cannot flag a vulnerability that requires understanding how two functions interact. The practical test: can a fresh Claude call with only the subtask's input produce a correct, complete result? If the answer requires context you stripped away, the decomposition is too narrow.
Should I decompose tasks statically at design time or dynamically at runtime?
Both have a place. Static decomposition is faster and more predictable — it works well for pipelines with known structure (e.g., a document processing workflow always has the same stages). Dynamic decomposition (where the coordinator decides at runtime) handles variable or unknown task structures better but requires a more capable coordinator model and more extensive error handling. Most production systems use static decomposition for the outer structure and allow the coordinator limited dynamic adjustments within each stage.
What is the relationship between task decomposition and context window management?
Decomposition is one of the primary tools for context window management. By scoping each subtask narrowly, you prevent any single agent from accumulating a large context. This directly reduces per-call token costs and avoids the [position effects](/glossary/position-effects) that degrade quality when the context window is nearly full. Each subagent gets only the context relevant to its subtask, and the coordinator synthesises results without needing all the raw detail in a single call.