Least-to-most prompting: solve smaller dependencies first

Last updated: 7 Oct 202611 min read

tutorial

Least-to-most prompting decomposes a hard request into smaller questions and resolves them in dependency order. This is useful when the final answer depends on several facts or transformations that can be checked separately. The decomposition itself can be wrong: an omitted dependency can make every later step look internally consistent while the conclusion fails. Name the required input, output, and validation rule for each subproblem. If a step cannot be verified, stop or mark subsequent answers conditional rather than passing an unsupported value forward.

Operational case

A retailer asks whether a delayed shipment qualifies for a customer credit. First identify the contract version effective on the ship date. Next extract the promised delivery window, then compare it with signed arrival evidence, then determine whether an exclusion applies. Only then calculate a credit under the verified rule. The model initially skips the exclusion because the customer message is persuasive. A dependency checklist catches the missing step. If the arrival signature is absent, the process can explain the pending evidence but cannot issue a credit amount.

Order OR-427; contract version -> promised window -> signed arrival.
Next: exclusion status -> verified credit rule -> amount.
Gate after each step: source ID, value, uncertainty.
If signed arrival missing: stop before eligibility and amount.
Final answer: checked result or named missing dependency.

Performance and operating cost

With S subproblems, a sequential workflow usually needs O(S) decisions and keeps O(S) intermediate results; dependent calls add their latencies rather than running in parallel. Validation can save rework by stopping early, but an over-split task wastes calls and creates more places for errors to propagate. Compare the decomposition with a direct baseline on the same cases. The useful measure is final decision accuracy under the same evidence and cost budget, not the apparent neatness of intermediate prose.

Common Mistakes

Do not skip a dependency because an answer feels obvious.
Do not carry an unverified intermediate result into an irreversible action.
Do not split a simple lookup into needless model calls.

Connected lessons

prompt engineering

reasoning patterns