Decomposition: Break the Task Down

Don’t ask a model to do a hard thing in one leap. Split it into small steps it can nail — and that you can check.

Building with AI · Lesson 40 · 10 min read

You ask a model to “read this contract and produce a risk report with sourced clauses, a summary, and recommendations” — and you get something plausible but subtly wrong, and you can’t tell where it went off. The most reliable fix in advanced prompting isn’t a magic phrase; it’s structural: stop asking for the whole thing at once. You met a version of this for agents (decomposing goals) — here it’s the core prompting skill. Hold the question: why does one big ask fail where the same work, split into steps, succeeds?

Big asks compound small errors

A complex task is really many sub-tasks welded together. Asked to do all of them in one pass, the model makes a small slip early (misreads a clause), and every later step builds on that slip — the errors compound, and the whole output drifts. Worse, you get one blob and can’t see which step failed. Decomposition breaks the task into an explicit sequence of smaller steps, each simple enough that the model reliably gets it right, and each checkable on its own. It’s the same “one clear step” instinct that makes good lessons and good tools — applied to prompting.

Two ways to decompose: in one prompt, or across prompts

You can decompose within a single prompt — “First, list the clauses. Second, rate each for risk. Third, write the summary.” — which forces the model to march in order rather than leap to the end (a cousin of chain-of-thought from lesson 6). Or you can decompose across multiple prompts/calls, feeding each step’s output into the next, so you can inspect and even correct between steps. Multi-call decomposition is more work but far more controllable: it turns an opaque mega-task into a pipeline you can debug (recall the failure-categories mindset from lesson 8 — now you can tell exactly which stage broke).

One ask vs a decomposed pipeline:
• One ask: “Analyze this transcript and give me action items with owners and due dates.” → a plausible list, some owners wrong, no way to see why.
• Decomposed: (1) extract every commitment as a quote; (2) for each, identify the owner; (3) for each, find any date; (4) format. Now if owners are wrong, you know it’s step 2 — and you can fix just that step.

Decompose to the level you can verify

How far to break it down? Until each step is something you could check. If a step is still “do something vague and complex,” split further; if you can look at a step’s output and say pass/fail, you’ve gone far enough (this is exactly the evaluation mindset from Module 3, applied per-step). Decomposition also unlocks the rest of this module: once a task is steps, you can add reasoning to the hard ones, vote across the uncertain ones, and pin formats on the structured ones. The mega-prompt that tries to do everything at once is the beginner’s move; the pipeline of small, checkable steps is the professional’s.

Decomposing a research task into a debuggable pipeline:
1. Goal: “summarize the key findings of these five papers and note where they disagree.”
2. Step 1: for each paper, extract its main claims as bullet points (check: are the bullets accurate?).
3. Step 2: line up claims on the same topic across papers (check: are they really about the same thing?).
4. Step 3: flag agreements and disagreements; Step 4: write the summary. If the final summary invents a disagreement, you trace it to step 2 and fix that — instead of re-rolling the whole opaque task and hoping.