Ask a language model to do something genuinely complex in a single prompt and you often get a confident, mediocre answer that collapses several decisions into one undifferentiated blob. The model did not fail because the task was impossible; it failed because the task contained five subtasks, and squeezing all five into one generation gave none of them the attention they needed.
Decomposition prompting is the discipline of breaking a complex task into an ordered sequence of smaller, well-defined steps, each handled by its own focused prompt, with outputs flowing from one step to the next. This guide is the thorough reference for someone serious about the technique. It covers why decomposition works, how to identify the seams along which to split a task, how to sequence and connect the pieces, and how the approach fails when applied carelessly.
The payoff is twofold. Decomposed tasks produce better output because each step is simpler and more constrained. They are also far easier to verify, because a human can inspect each intermediate result instead of trying to judge one opaque final answer. For high-stakes work, that verifiability is often the whole point. If you are new to the idea, the gentler introduction in Splitting Big Asks Into Steps a Model Can Actually Handle is a good starting point before this reference.
Why Decomposition Improves Results
The technique is not just organizational tidiness. It changes what the model can do well.
One reasoning load per step
A model allocates its reasoning across whatever you ask in a single prompt. Pack in many subtasks and each gets a thin slice. Give each subtask its own prompt and the model brings full attention to a simpler problem. The output quality difference is often dramatic for genuinely multi-part tasks.
Errors stop compounding silently
In a single monolithic generation, an early wrong assumption silently corrupts everything after it, and you cannot see where it went wrong. Decomposition surfaces each intermediate result, so a wrong assumption shows up at the step that made it, before it poisons the rest.
Constraints become enforceable
It is hard to enforce ten constraints in one prompt; the model drops some. Distributed across focused steps, each constraint applies to a smaller context where it actually holds. This is why decomposition often outperforms an elaborate single prompt that tries to specify everything at once.
Finding the Seams
The hard skill in decomposition is knowing where to cut. Good seams make the pieces clean; bad seams create dependencies that tangle.
Decompose by distinct decisions
The most reliable seam is a distinct decision or transformation. "Analyze the document," "extract the obligations," "draft a summary," and "check the summary against the source" are four decisions, each a natural step. Splitting along decisions keeps each step coherent.
Separate gather from generate
A common and powerful split is between gathering or structuring information and producing output from it. Have one step assemble and organize the relevant facts, and a later step write from that structured material. This mirrors how grounding works in regulated drafting and is one reason the technique transfers to careful domains.
Avoid splitting tightly coupled reasoning
Not everything should be split. If two parts must be reasoned about together to be correct, forcing them into separate steps loses the joint reasoning. The skill is recognizing when a seam is real versus when you are amputating a single thought. Over-decomposition is a real failure mode, covered later.
Sequencing and Connecting Steps
Once you have the pieces, the order and the handoffs determine whether the chain holds.
Order by dependency
Each step should consume the outputs of the steps it depends on. Map the dependencies first, then sequence so that nothing runs before its inputs exist. A step that needs an extracted list cannot run before extraction; getting this order wrong produces steps operating on missing information.
Pass structured intermediates
The output of one step is the input to the next, so make intermediates structured and explicit rather than loose prose. A clean list or labeled set of fields hands off far more reliably than a paragraph the next step has to re-parse. Clear interfaces between steps are what make the chain robust.
Insert verification as its own step
Treat checking as a first-class step, not an afterthought. A dedicated verification step that compares a draft against source, or validates extracted data, catches errors at the seam where they appear. This is the same logic that makes decomposition valuable for the legal drafting workflow in Making Legal Drafting With AI a Process Anyone Can Run.
Patterns That Recur
Certain decomposition shapes show up across many complex tasks.
Extract, transform, verify
The workhorse pattern: pull structured information out, transform it into the desired output, then verify the output against the original. It applies to summarization, analysis, and data work alike, and its built-in verification step is what makes it trustworthy.
Plan then execute
For open-ended tasks, have one step produce a plan or outline, review it, then have later steps execute against the approved plan. Reviewing the plan before execution catches misdirection cheaply, before effort is spent building on a flawed foundation.
Generate then critique
Produce a draft in one step, then have a separate step critique it against explicit criteria, then revise. The separation matters: a model critiquing in a fresh step catches issues it glossed over while generating. For a concrete, sequential walkthrough of running these patterns by hand, see Running a Complex Task Through One Sub-Prompt at a Time.
Where Decomposition Goes Wrong
The technique has failure modes worth naming so you can avoid them.
Over-decomposition
Splitting a task into too many trivial steps adds overhead and handoff friction without improving quality, and can sever reasoning that needed to stay joined. If a step is so small it adds no value, merge it back. More steps is not automatically better.
Lossy handoffs
If an intermediate output drops information the next step needs, the chain fails quietly. Design handoffs to carry everything downstream steps require, and verify intermediates as carefully as final outputs.
Losing the thread
Long chains can drift from the original goal as each step optimizes locally. Keep the overarching objective present, restating it where steps risk losing sight of it, so the chain stays aimed at the actual task rather than wandering.
Decomposition in High-Stakes Domains
The technique earns its keep most clearly where being wrong is expensive.
Verifiability as the main attraction
In domains like legal drafting, financial analysis, or compliance, the headline benefit of decomposition is not raw quality but the fact that a human can inspect each intermediate. A single opaque generation gives a reviewer nothing to check until the end; a decomposed chain exposes the extracted facts, the transformations, and the draft as separate, verifiable artifacts. For consequential work, that visibility is itself a control, which is why the approach maps so naturally onto careful workflows like the one in Making Legal Drafting With AI a Process Anyone Can Run.
Grounding lives inside the decomposition
The separation between gathering and generating is exactly where source-grounding fits. An early step assembles the authoritative material; later steps draft strictly from it. Decomposition makes grounding a visible, enforceable stage rather than a hope, which is much of why the two techniques reinforce each other in regulated drafting.
Matching effort to consequence
Not every task in a high-stakes domain needs deep decomposition. Reserve the heavier chains for documents where an undetected error would be costly, and use simpler approaches for routine work. The skill is calibrating the depth of decomposition to the stakes, spending verification effort where it actually protects something.
Frequently Asked Questions
When should I decompose instead of writing one strong prompt?
Decompose when a task contains multiple distinct decisions or transformations, when errors would compound invisibly, or when you need to verify intermediate results. For genuinely simple tasks, a single well-formed prompt is better; decomposition adds overhead that only pays off on complexity.
How do I know where to split a task?
Split along distinct decisions or transformations, and separate gathering information from generating output. Avoid splitting reasoning that must happen jointly to be correct. The right seams produce coherent, loosely coupled steps; the wrong ones create tangled dependencies.
Does decomposition make verification easier?
Substantially. Each intermediate result is inspectable, so a human can catch a wrong assumption at the step that made it rather than judging one opaque final answer. This verifiability is often the main reason to decompose for high-stakes work.
Can I overdo it?
Yes. Over-decomposition splits a task into trivial steps that add handoff friction without improving quality and can sever reasoning that needed to stay joined. If a step adds no value, merge it back; more steps is not inherently better.
How do I connect the steps reliably?
Pass structured, explicit intermediates rather than loose prose, order steps by dependency so nothing runs before its inputs exist, and design handoffs to carry everything downstream steps need. Clean interfaces between steps are what make the chain robust.
What are the most useful decomposition patterns?
Extract-transform-verify for data and analysis, plan-then-execute for open-ended work, and generate-then-critique for quality. Each builds in a checkpoint that catches errors before they propagate, which is the core value of the approach.
Key Takeaways
- Decomposition splits a complex task into ordered, focused steps, giving each subtask full reasoning attention.
- It surfaces intermediate results so errors are caught where they occur instead of compounding silently.
- Find seams along distinct decisions and separate gathering information from generating output.
- Connect steps with structured intermediates, dependency ordering, and dedicated verification steps.
- Recurring patterns include extract-transform-verify, plan-then-execute, and generate-then-critique.
- Avoid over-decomposition, lossy handoffs, and drift from the original goal across long chains.