Decomposing complex problems

What you’ll be able to do

• Choose a decomposition axis (by stage, by partition, by capability, by uncertainty) that matches the problem’s structure
• Assign each subtask to model, deterministic code or a human based on what it requires
• Set subtask granularity to balance attention focus against handoff overhead and lost context
• Define interfaces and acceptance criteria so each subtask is independently testable
• Plan recombination and replanning: integration passes, dependency ordering and adaptive decomposition

What you need to know

Why decompose at all

Large tasks fail in recognizable ways when attempted in one pass: attention spreads thin and middle sections get skimmed, instructions for one part bleed into another, the output is too long to validate, and when something is wrong nobody can tell which part caused it. Decomposition gives each piece a focused context, a checkable output and an owner. It also costs something: every boundary is a handoff where context can be lost and latency added. The design problem is choosing where to cut.

Pick the axis that matches the problem

• By stage: the work has a natural sequence (classify, extract, validate, draft). Each stage gets a focused prompt; outputs feed the next. Good for predictable processing.
• By partition: the same operation over many independent units (files, contracts, regions, time periods), then a merge. This is map-reduce; partitions can run in parallel or in batch. The merge needs its own design.
• By capability: different parts need different skills, tools or permissions (retrieval, calculation, writing, a privileged action). Often maps to separate tools, separate code steps or separate agents.
• By uncertainty: you don't yet know the shape of the work. Decompose into "map the terrain" first (inventory, dependency graph, reproduction of the problem), then generate the next subtasks from what was found.

Real problems combine axes. A contract-portfolio review might partition by contract, run a fixed stage chain inside each partition, and finish with a cross-portfolio aggregation that is by capability (code for totals, the model for narrative).

Assign each piece to the right executor

Once the pieces exist, ask of each: does it need language understanding or judgment, is it exact and rule-bound, or does it need accountable human sign-off? Arithmetic, date logic, lookups, joins, schema checks and deduplication belong in code. Interpretation, extraction from messy text, drafting and comparison under fuzzy criteria belong to the model. Approvals with legal, financial or safety consequences belong to people. Decomposition is often where an architect discovers that a third of the "AI task" is ordinary software.

Granularity: focus versus handoff cost

Too coarse and you are back to attention dilution. Too fine and each piece lacks the context it needs: a reviewer of one function cannot see that its caller changed, a summarizer of one page cannot see that page three contradicts page nine. Signals that you have cut too fine include pieces that need most of the others' context to act, rising handoff volume, and integration passes that keep finding problems the pieces could not see. Signals that you have cut too coarse include inconsistent depth across the output and errors you cannot localize.

Interfaces and acceptance criteria

Treat each subtask like a function: defined inputs, a defined output schema, and an acceptance test that can run on its own. That lets you build evaluation sets per stage, find which stage regressed after a change, and swap a model or prompt for one stage without retesting everything by hand. It also lets you put a cheaper or faster model on stages that do not need the most capable one, which is a cost lever only decomposition provides.

Recombination is a step, not an afterthought

Pieces that are each correct can still combine into something wrong: duplicated findings, contradictory conclusions, an interface change in one file that breaks callers in another, totals that do not reconcile. Design the recombination explicitly:

• an integration pass that receives the per-piece results and looks specifically at cross-piece issues;
• deterministic reconciliation for anything countable (sums, ID matches, coverage checks);
• dependency ordering: model the subtasks as a graph, run independent nodes in parallel, and run dependent ones only after their inputs are validated.

Static plans versus adaptive replanning

A fixed plan suits work whose steps you can list in advance and want done the same way every time. Investigations (root-causing an outage, assessing an unfamiliar codebase, researching a new market) need an adaptive plan: map first, prioritize by impact, then let each finding add, drop or reorder subtasks. The professional design keeps adaptivity bounded, with a budget, a definition of done, and a record of why the plan changed, so the result remains auditable.

Key concept

Cut along the problem’s real seams, give every piece an interface, an executor (model, code or human) and an acceptance test, and design recombination and replanning as first-class steps.

Questions here describe output that is shallow in places, correct pieces that combine badly, or a plan that could not adapt. The right answer changes the decomposition: the axis, the granularity, the integration step, or which executor owns a piece.

Practice scenario

Build exercise — Decompose a real task into a dependency graph

Advanced · 45 min

What you’ll learn

• Choosing decomposition axes deliberately
• Assigning executors and acceptance tests per subtask
• Designing recombination and replanning

1. Take a complex task currently done in one prompt or by hand and draw it as a graph of subtasks, labeling the axis each split follows.

   • Why: Making the axis explicit shows whether the cuts follow the problem’s structure.
   • You should see: A mix of stage, partition and capability splits, and a clear set of independent nodes that could run in parallel.

2. For each node, mark model, code or human, and write a one-line acceptance test.

   • Why: Per-node tests localize failures and let you evaluate and change pieces independently.
   • You should see: Several nodes move to code, and every model node has a schema it must satisfy.

3. Add the recombination node: what it checks across pieces, what is reconciled deterministically, and what triggers replanning.

   • Why: Cross-piece errors are invisible to the pieces themselves.
   • You should see: At least one check (coverage, totals, interface consistency) that no single subtask could perform.

Exam traps

Decomposing so finely that context is lost at every handoff

Pieces that need each other’s context perform worse apart. Merge them or pass the shared context explicitly.

Running one giant prompt over everything and accepting attention dilution

Depth becomes uneven and errors cannot be localized. Split along stages or partitions with focused passes.

Splitting the work but never designing the integration step that catches cross-piece issues

Correct pieces can combine into inconsistent results. Add an integration pass and deterministic reconciliation.

Fixing the plan up front for an investigation whose steps depend on what is found

A fixed list misses what discovery reveals. Map first, then replan from findings within a budget.

Leaving deterministic sub-steps (math, lookups, format checks) to the model

Exact operations are cheaper and reliable in code. Reserve the model for language and judgment.

Defining subtasks without acceptance criteria, so failures surface only in the final output

Without per-piece tests, every defect becomes an end-to-end investigation. Give each piece a schema and a check.

Sources

• Claude Developer Platform Docs
• Anthropic
• Anthropic, Claude Certified Architect – Professional Exam Guide v1.0 (July 2026)