Why multi-step planning turns a small reasoning slip into a large outcome failure

A plan is a chain, and a chain inherits the weakest link in it. The teams that ship long-horizon agents design for per-step correction, not per-model brilliance.

B

Balagei G Nagarajan

4 MIN READ


A long planning chain where one faint crack near the start widens into a break by the end
98 to the twentieth power, which is roughly 67%.
— from “Why multi-step planning turns a small reasoning slip into a large outcome failure”

Key facts.

  • MAKER solved a task of over one million LLM steps with zero errors only by decomposing it into focused microagents and applying error correction at every step, because models have a persistent per-step error rate that otherwise derails the run within a few hundred steps. source
  • PlanBench, the planning benchmark from Valmeekam and colleagues, finds LLMs fall well short on plan generation and on reasoning about changes to a plan, even in simple domains like Blocksworld. source
  • On WebArena's 812 long-horizon web tasks, the best LLM agent finished 14.41% end to end against a human rate of 78.24% and the gap is largest exactly where a plan has many dependent steps. source

Why does a 2% step error become a 50% task failure?

The math is unforgiving. If each step in a plan is right 98% of the time, a twenty step plan is right about 0.98 to the twentieth power, which is roughly 67%. Stretch it to forty steps and you are near a coin flip. Nothing about the individual step looks broken. The agent picked a reasonable next action, the tool returned a plausible result, the reasoning read fine. The failure lives in the composition, not in any one link and that is precisely why it hides from spot checks. You review a step, it looks correct, you move on and the chain quietly accumulates the errors you did not multiply out.

This is also why "add a smarter model" disappoints. A smarter model lowers the per-step error rate, which helps, but the compounding is exponential in the number of steps and only linear in the per-step gain. Past a certain plan length, the only thing that bends the curve is catching and fixing errors as they happen, not hoping they never occur.

A waterfall chart showing task success dropping step by step as a fixed per-step error compounds

What does designing for correction actually look like?

It looks like structure. Break the long plan into steps small enough that each one has a checkable result. Put a cheap verifier on the output of each step so a wrong move is caught before the next step inherits it. Where a step is high consequence, hold a vote or a second opinion rather than a single pass. This is the shape MAKER used to reach a million steps and it is the shape that production planning needs even at twenty steps. The agent does not become reliable because it stopped making mistakes. It becomes reliable because the mistakes stop traveling.

ApproachWhat it assumesWhat happens at 40 steps
Trust the chainThe model rarely errsCompounding pushes success toward a coin flip
Correct each stepThe model errs at a small fixed ratePer-step checks stop errors from multiplying

This is the work VibeModel does as the Pattern Intelligence Layer. We model the patterns a reliable plan follows, where the checkable points sit, where a step's output has to be confirmed before the next one runs, so the planning chain holds at the length production demands rather than the length a demo survives.

Frequently asked questions

Can a bigger model hold the long chain together?
In MAKER a frontier model on Hanoi derails fast until per-step checks reach a million; an unchecked chain multiplies its cost. (arXiv:2511.09030)

Is this just a context length problem?
No. Even with the full plan in context, an uncorrected per-step error rate compounds. The fix is step-level verification, not a bigger window.

Does a reasoning model remove the need for correction?
It lowers the per-step rate but does not remove compounding. MAKER's result came from non-reasoning models plus correction, not from a stronger model alone.

How short should a step be?
Short enough that its output can be checked cheaply and independently. If you cannot verify a step's result, it is too big.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.