What you’ll be able to do
- Tell when a request should be broken into stages rather than sent as one prompt
- Lay out a sequence of steps where each produces something you can review
- Carry the right results forward from one step to the next
What you need to know
Why one giant prompt underperforms
Imagine asking, in one message: "Read these 40 customer interviews, find the main pain points, rank them by business impact, propose three product changes, and write a board presentation about it." Claude will produce something, but every stage is compressed. Themes get merged, the ranking rests on themes you never saw, and the presentation confidently builds on all of it. If something went wrong in stage one, you won't know until you're reading slides.
Decomposition fixes this by turning one opaque leap into several visible steps. Each step is simpler, so Claude does it better, and each output is something you can check before it becomes the foundation for the next.
Signs a request needs breaking down
- Several different kinds of work in one ask: gathering information, analyzing it, deciding, then writing.
- Lots of source material, such as many documents, a long transcript or a big spreadsheet, where the first job is just to extract what matters.
- A decision in the middle that you, not Claude, should make (which option to pursue, which audience to prioritize).
- A long final product, such as a report with many sections, where the structure should be agreed before anything is written.
- You'd do it in stages yourself. If a human analyst would hand you an interim result for review, Claude's version should have that checkpoint too.
The opposite also matters: a short email, a quick rewording or a single question doesn't need a five-step plan. Decomposition has a cost in time and turns, so use it when the task is genuinely complex.
A typical pattern: gather, structure, decide, produce
Many business tasks fit this sequence:
- Gather and extract — "From these interview notes, list every pain point mentioned, with the interviewee and a short quote." Check it: is anything missing or invented?
- Structure and analyze — "Group these pain points into themes and count how many interviews mention each." Check the groupings make sense.
- Decide — you choose which themes to act on, perhaps after asking Claude for pros and cons of each.
- Outline, then produce — "Propose an outline for a 10-slide board update based on the themes I chose." Approve or adjust the outline, then have Claude draft section by section.
Notice that the human decision sits in the middle of the sequence. Decomposition is not only about making Claude more accurate; it also creates natural points where you apply judgment that should stay with a person, such as choosing priorities, approving a recommendation or deciding what goes to leadership. Keep extraction separate from interpretation, too. When facts and opinions arrive in the same paragraph, it is much harder to check the facts.
Asking Claude to propose the plan is a decomposition technique in itself: "Before doing anything, list the steps you'd take to complete this and what you'd need from me." You can then edit the plan before work starts.
Carrying results forward
Steps only help if each one builds on the verified output of the last. Within one conversation, Claude can see the earlier turns. If you move to a new chat, perhaps because the conversation has grown very long, bring forward a concise summary of what was decided and the checked output, not the whole history. For a recurring multi-step workflow, a Project lets you keep the shared instructions and reference files in one place so every chat starts with the same context. Artifacts are handy for the intermediate products you keep refining, such as an outline or a comparison table.
Know where decomposition ends
Some "complex requests" are complex because they need software: pulling data automatically from several systems every week, triggering actions in other tools, or running without a person in the loop. Breaking that into more chat steps doesn't solve it. That's a solution-design question to raise with a Claude developer or architect.
Key concept
Break a complex request into ordered steps that each produce something you can check, and pass only verified results to the next step.
Exam questions often show a single sprawling prompt that produced a weak or unreliable result. The best answer usually stages the work with a review point between steps, rather than adding more instructions to the same mega-prompt or switching to a bigger model.
Practice scenario
Work it through, then open this
The extraction, comparison, decision and writing all happened in one leap, so an error in extracting the prices flowed straight into the recommendation and memo. Re-running the same prompt might hide the error rather than fix it. A better approach: first ask Claude to extract the key terms (price, delivery time, contract length, support) from each proposal into a table, with the page or section each figure came from. She verifies the table against the proposals. Then she asks for a comparison against her criteria, makes the decision herself, and finally has Claude draft the memo from the approved table. Each stage is checkable, and the memo rests on figures she has confirmed.
Hands-on exercise — Stage a multi-part task
Beginner · 20 min
What you’ll learn
- How to have Claude propose a plan before doing the work
- Where to place review checkpoints
- How staged output compares with a single all-in-one answer
-
Pick a real multi-part task (for example, “turn these meeting notes into an action plan and a team update”). Ask Claude: “Before you start, list the steps you’d take and what you’d need from me at each one.”
- Why: Having the plan in view lets you correct the approach before any work is done.
- You should see: A numbered sequence you can edit, such as extract decisions, list actions with owners, then draft the update.
-
Run only the first step and check its output against your source: anything missing, merged or made up?
- Why: Errors are cheapest to fix at the first step, before later steps build on them.
- You should see: At least one thing you’d adjust, such as an action without an owner or two items merged together.
-
Run the remaining steps, giving Claude your corrected output each time. Then, in a fresh chat, send the original task as one prompt and compare.
- Why: The comparison shows what decomposition bought you.
- You should see: The staged result is more accurate and closer to what you need; the one-shot version is plausible but harder to trust.
Exam traps
Cramming a multi-stage task into one enormous prompt
Every stage gets compressed and mistakes in early stages stay hidden inside the final answer.
Moving to the next step without checking the previous step’s output
Decomposition only helps if you review the interim result. An unchecked error just travels further.
Splitting a simple task into steps it doesn’t need
A short, single-purpose request is fine as one prompt. Staging has a cost in time.
Mixing gathering, analyzing and writing in the same step
Keep extraction separate from interpretation and from polished writing, so you can verify the facts before they’re dressed up.
Letting each step run in a separate chat with none of the earlier results
A new chat doesn’t see previous conversations unless you bring the results across or use a Project or memory. Carry forward a summary of what was decided.
Treating a task that needs automation or system integration as just a longer chat
When the work needs to run automatically or connect systems, more prompt steps won’t get you there. Escalate to a Claude developer or architect.
Sources
- Anthropic, Claude Certified Associate – Foundations Exam Guide v1.0 (July 2026)
- Claude Help Center
- Claude Docs (includes prompt engineering guidance)