1.2 Decomposing Complex Requests Into Checkable Steps

Complex requests fail for a predictable reason: they ask Claude to do too much at once, in a single undifferentiated pass, with no natural place to check the work along the way. Hand over 40 raw interview notes with the instruction "what should we do?" and you'll get an answer -- but you have no way to tell whether it correctly identified the real themes, missed a cluster of complaints, or jumped to a recommendation that doesn't actually follow from the data.

**Task decomposition** is the fix: break a large or fuzzy goal into ordered, checkable sub-steps instead of one large ask. This isn't about being more polite to the model or writing more words -- it's a structural change to how the work is organized, and it's tested as its own skill because it's exactly the kind of judgment call a business user has to make routinely: when is a task simple enough for one prompt, and when does it need to be broken up?

The first pattern is **sequential decomposition**, also called **prompt chaining**: complete step one, review the result, then feed that reviewed result into step two, and so on. The classic example: (1) extract the key complaints from 40 survey responses, (2) group those complaints into themes, (3) draft an action memo from the themes. Each step's output becomes the next step's input -- but only after a human has looked at it.

The review checkpoint is not optional overhead -- it's the entire point of choosing this pattern over a single prompt. If the theme-grouping step misclassifies a complaint, catching it before it flows into the recommendation memo is far cheaper than discovering a wrong recommendation at the end and having to trace it back through three stages of reasoning to find where it went wrong.

Not every multi-part task needs a human checkpoint between every step. For a moderately complex task, a single prompt can still be decomposed internally by spelling out ordered sub-steps: "First summarize the contract. Then list the three riskiest clauses. Finally recommend one change per clause." This gives Claude the same ordered structure as prompt chaining, but in one turn, because the task doesn't warrant a human review between each sub-step.

The judgment call is choosing between the two patterns, and it comes down to how much a mistake in an early sub-step would cost, and how confident you are that the whole thing can be judged correctly in one look at the final output. A three-part contract review that produces one integrated response is usually fine as a structured single prompt; a 40-document synthesis feeding into a stakeholder-facing memo is usually worth chaining and checking.

The reason decomposition matters as much as it does is the verification it unlocks. When a task is broken into ordered sub-steps, you can check each intermediate result -- the extracted complaints, the theme groupings -- instead of trying to judge one giant, undifferentiated output at the end. If something goes wrong downstream, it's traceable to a specific, reviewable step rather than buried somewhere inside a single large response.

This mirrors the *Delegation* and *Description* ideas in Anthropic's AI Fluency framework: describing work clearly and handing off well-scoped pieces, rather than a single sprawling ask, is what makes delegation to an AI system (or to a person) actually work. A vague, all-at-once ask isn't more efficient delegation -- it's an abdication of the scoping that makes the handoff succeed.

Task Statement 1.2 questions typically describe a multi-part business task and ask which approach handles it best, or ask you to distinguish real decomposition from something that merely looks like it.

• 1.Trying to solve a multi-part problem in a single vague prompt when the pieces should be sequenced and checked -- e.g., "what should we do?" over 50 raw interview notes instead of extract, group, then recommend.
• 2.Confusing decomposition with simply making the prompt longer. Decomposition is about structure and order, not word count -- a long but unstructured prompt is not decomposed.
• 3.Choosing sequential chaining for a task so simple that the review checkpoints add friction without adding safety.
• 4.Choosing a single structured prompt for a task large or high-stakes enough that an early error would be costly to trace later.

The exam consistently rewards matching the decomposition pattern -- or the decision to decompose at all -- to the actual complexity and risk of the task, not to a fixed rule like "always chain" or "always use one prompt."