Why architecture matters here
The architectural payoff of least-to-most comes from a property of how models fail on hard problems: the failures are usually compositional, not local. Ask a model to compute each of four sub-quantities in isolation and it gets them right; ask it to compute the final answer that depends on all four at once and it drops one, or conflates two, or loses track of which intermediate belongs where. The error is not in any single reasoning step but in juggling several simultaneously. Decomposition converts the one hard juggling act into a series of single-ball catches, each of which the model can do reliably.
Answer-passing is what makes decomposition more than just listing steps. Chain-of-thought also breaks a problem into steps, but it does so within a single generation, where the earlier steps are just earlier tokens the model wrote and may drift away from or contradict later. Least-to-most makes each subanswer a committed, explicit input to the next step's prompt: subproblem three is solved in a fresh, focused context that literally contains the verified answers to subproblems one and two as given facts. This turns fuzzy self-consistency into hard data dependency — step three cannot forget step one's answer because it is printed right there in its prompt.
The ordering from least to most is not cosmetic; it is what guarantees the dependencies are satisfiable. If subproblem B needs the answer to subproblem A, A must come first, and the whole point of ordering easiest-to-hardest is that it tends to respect the dependency structure — foundational quantities are usually both simpler and prerequisite. When the controller reaches the hardest subproblem, everything it depends on is already solved and present, so the 'hardest' step is, in context, nearly trivial: it is just combining known results. The difficulty has been amortized across the sequence rather than concentrated at the end.
Contrast this with asking for the answer directly, and the leverage is clear. A single-shot prompt forces the model to simultaneously (a) figure out how to break the problem down, (b) solve every piece, and (c) combine them — all in one pass, all in one context, with no chance to check any piece. Least-to-most separates these concerns: decomposition is its own step you can inspect, each solve is isolated and checkable, and combination is the final solve fed by verified inputs. Separation of concerns is as valuable in prompting as in software; it is what makes the failure of any one step localizable and fixable instead of hidden in an opaque wall of reasoning.
There is also a reliability-through-structure argument that explains why this belongs in an application rather than being left to a cleverer prompt. Because the pipeline is explicit, you can attach a validator to each subanswer, cache subproblems that recur, retry a single failed step without redoing the whole chain, and bound the depth so a pathological decomposition cannot loop forever. None of that is possible inside a monolithic reasoning generation. The structure that least-to-most imposes is exactly what gives the surrounding system the hooks it needs to make an inherently stochastic process dependable.
The architecture: every piece explained
Trace the components. The complex problem enters and goes first to the decomposition prompt, which asks the model not to solve anything yet but to produce an ordered list of subproblems whose answers, in sequence, build up to the solution. The prompt is engineered so the list ends with the original question restated — that final entry is what makes the last solve produce the goal. The output is parsed into a subproblem queue ordered easiest to hardest, which the controller will walk in order.
The solver step is the workhorse, invoked once per subproblem. For each, the context builder assembles a focused prompt: the original problem for grounding, the current subproblem to solve, and the accumulated answers — the solved prefix of all earlier subproblems, presented as established facts. The model solves just this one subproblem against that context and returns a subanswer. Because the prompt contains the concrete answers to prior steps, the model is never asked to re-derive them; it builds strictly on top of what is already known.
The accumulated answers store is the growing solved prefix, and the context builder is the component that decides how much of it to inject and how. Naively you append every prior subanswer verbatim, but as the chain grows the context balloons, so a real builder is selective — injecting the subanswers the current step actually depends on, possibly summarizing older ones. This selectivity is where a lot of the engineering lives: too little context and a step lacks a dependency; too much and you pay tokens and dilute attention on the parts that matter.
The validator is what turns the chain from fragile to robust. After each solver step it checks the subanswer — with a rule (does this number satisfy the constraint?), a second model call (is this consistent with the prior answers?), or a tool (execute the code, run the query) — before the answer is committed to the accumulated store. This matters because least-to-most's greatest weakness is error propagation: a wrong subanswer poisons every later step that depends on it. Validating each step catches the error where it happened, when it is cheap to retry that one step, rather than letting it cascade into a confidently wrong final answer. The cache/memo complements this by storing solved subproblems so identical or equivalent subproblems across a batch are solved once.
The controller ties it together and enforces the limits that keep the pattern safe. It loops over the queue, invokes solve-then-validate for each subproblem, appends validated answers to the accumulated store, retries a failed step a bounded number of times, and halts either when the queue is exhausted (the last subanswer is the goal) or when a step fails irrecoverably. Crucially it bounds depth and tokens: a decomposition that produces hundreds of subproblems, or a step whose context grows without limit, must be capped so a pathological input cannot run up unbounded cost. The controller is where least-to-most stops being a prompt trick and becomes an operable component with predictable cost and failure behaviour.
End-to-end flow
Walk a concrete problem: 'A store had 120 apples. It sold 40% on Monday, then received a delivery equal to a third of what remained, then sold a quarter of the new total on Tuesday. How many apples are left?' A single-shot answer often slips on one of the compounding percentages. Least-to-most handles it by decomposing first.
The decomposition prompt returns an ordered queue: (1) How many apples were sold Monday? (2) How many remained after Monday? (3) How large was the delivery? (4) What was the total after delivery? (5) How many were sold Tuesday? (6) How many are left? — which is the original question. Each is trivial in isolation; the difficulty was only in chaining them, and the chain is now explicit.
The controller solves subproblem 1: 40% of 120 is 48. The validator checks it (a percentage of a known quantity, easily verified) and commits '48 sold Monday' to the accumulated store. Subproblem 2's prompt now contains that fact, so the model answers 120 − 48 = 72 remaining — it does not recompute the 48, it reads it. Subproblem 3, with '72 remaining' in context, answers a third of 72 is 24. Each step is a single, local computation against concrete given facts.
The chain continues: subproblem 4 combines 72 + 24 = 96, subproblem 5 computes a quarter of 96 = 24 sold Tuesday, and subproblem 6 — the goal — answers 96 − 24 = 72 apples left, with every input it needs already solved and printed in its context. The 'hardest' final step is, in context, just one subtraction, because least-to-most has front-loaded all the difficulty into earlier, isolated steps. The final subanswer is the final answer.
Now the error-handling path, which is where the architecture earns its keep. Suppose at subproblem 3 the model miscomputes a third of 72 as 21. Without validation, that 21 flows into steps 4, 5, and 6, and the final answer is confidently wrong with no indication of where it broke. With a validator — here a simple arithmetic tool that recomputes 72/3 — the error is caught immediately, the controller retries subproblem 3 alone (not the whole chain), the model corrects to 24, and the chain proceeds correctly. The cost of the mistake was one retried step, and the failure was localized to exactly where it happened, which is the decisive advantage of an explicit pipeline over a monolithic reasoning pass.