Decomposing complex problems

Why break a problem down — and why not

Anthropic’s “Building effective agents” gives the core reason: for complex tasks with several considerations, a model generally does better when each consideration is handled by its own call, because each call gets a simpler job and full attention. Decomposition also buys things an enterprise cares about beyond accuracy: intermediate results you can inspect and log, a fixed structure you can audit, independent pieces you can run in parallel, and simple pieces you can give to a cheaper model or to ordinary code.

The counterweight is just as real. Current Claude documentation notes that, with adaptive thinking and subagents, Claude handles most multistep reasoning inside a single request, and that explicit chaining is still useful when you need to inspect intermediate outputs or enforce a specific pipeline structure. Every split costs a round trip, and every handoff is a chance to drop context the next step needed — the “telephone game” Anthropic warns about for multi-agent systems in 1.4. Good decomposition finds the fewest pieces that make the problem tractable, checkable and cheap enough.

Six decomposition techniques

Most real problems use a combination, but each piece of a design should be recognisable as one of these shapes. The workflow patterns from 1.3 are the implementation; these are the ways of cutting the problem that lead to them.

Finding the seams

The most useful question is not “what are the steps?” but “what does each piece need to know?”. Two pieces that need the same large body of context belong together; splitting them forces one to re-read or to work from a lossy summary. Two pieces that need different context — one reads the contract, one reads the customer history — are a natural seam. Anthropic’s guidance on multi-agent systems makes the same point: divide by context, not by type of work.

The second question is which pieces need a model at all. Decomposition is where you pull deterministic work out of the prompt: arithmetic, totals, lookups, date rules, format validation and routing on known fields belong in code, which is cheaper and exact. Claude takes the pieces that need reading, judgement or writing. A person takes the pieces where the decision carries accountability. A design that asks one prompt to extract, calculate, judge and approve has not been decomposed; it has been hoped for.

The third is how each handoff is described. A piece’s output is the next piece’s input, so it needs a contract: a structured format, the fields that must be present, and what happens when they are not. Anthropic’s research system learned that vague task descriptions made subagents duplicate each other and miss the point; the fix was an explicit objective, output format, tool guidance and boundaries for every piece. The same discipline applies to a two-step chain as to a fleet of agents.

Work bigger than one context window

Some problems are too big for any single session, however well prompted. Anthropic’s work on long-running agents found two failure modes when an agent faced a large job whole: it tried to do everything at once and ran out of context midway, or it saw some progress and declared the job done. The fix was incremental decomposition. A first session set up the work: a structured list of every feature with a pass or fail flag, a progress notes file, a setup script and version control. Every later session took one item, completed and tested it, recorded progress and committed.

Claude’s prompting guidance generalises this: use the first context window to set up a framework and later windows to iterate on a to-do list; keep structured state such as test status in JSON and free-form progress in notes; and use version control as a log and set of checkpoints. It also notes that when a context window is cleared, starting fresh and letting the model rediscover state from files can work better than compaction. The long-running-agents write-up adds that JSON was chosen for the task list partly because models were less likely to change a JSON file inappropriately than a Markdown one.

{
  "job": "Migrate finance reports to the new warehouse",
  "items": [
    { "id": "R-014", "name": "Monthly accruals",  "status": "passing" },
    { "id": "R-015", "name": "Aged receivables",  "status": "failing",
      "note": "totals differ by FX rounding; see notes" },
    { "id": "R-016", "name": "Cost-centre spend", "status": "not_started" }
  ],
  "rule": "One item per session. Never delete or edit another item."
}

Traps the wrong answers are built from

You should now be able to

• Explain the benefits and costs of decomposing a problem, including when not to split.
• Recognise sequential, parallel, map-reduce, dynamic, incremental and generate-verify decompositions from a scenario.
• Find seams using dependencies and shared context rather than organisational roles.
• Separate deterministic steps for code from judgement steps for Claude and accountable decisions for people.
• Design structured handoffs and a check for each piece and for the whole.
• Plan work that exceeds one context window as small verifiable units with external state.