The Long-Horizon Problem: Why Capable Agents Still Cannot Finish Long Tasks
There is a research problem sitting underneath most of the disappointment with AI agents, and it is not a problem of intelligence. Systems that handle a three-step task competently fall apart on a thirty-step version of the same task, and the reason has less to do with reasoning quality than with arithmetic.
This is now one of the more active areas of AI research, and the work coming out of it in 2026 is considerably more interesting than the product discourse around agents would suggest.
The Arithmetic Nobody Likes
Start with the simplest model. If a task requires a sequence of steps and each step succeeds independently with probability p, the whole sequence succeeds with probability p raised to the number of steps.
The consequences are unforgiving. At ninety-five percent per-step reliability — which would be considered strong performance on most evaluations — a ten-step task succeeds under sixty percent of the time. At thirty steps it is under twenty-two percent. The per-step number looks excellent and the end-to-end number is unusable, and no amount of improvement in the former rescues the latter quickly, because the exponent does the work.
This model is too simple in ways that matter, and we will come to those. But it explains the basic shape of the observed problem: agent reliability does not decline gently with task length. It collapses.
What Recent Work Has Added
Several 2026 papers have moved past the naive model toward something more diagnostic.
Failures are not independent
The simple calculation assumes each step’s success is unrelated to the last. Empirically it is not. Once an agent commits to a wrong intermediate state, subsequent steps are conditioned on that error, and the failure probability rises rather than staying constant. Work published in early 2026 characterized this as canonical path deviation: the agent leaves the trajectory that would have solved the task and then operates competently within a state that no longer leads anywhere useful.
This distinction matters because it changes what a fix would look like. Independent failures argue for better per-step accuracy. Correlated failures argue for detection and recovery, which is a different research agenda.
Context degradation is a mechanism, not a limit
Long trajectories accumulate context, and models with nominally sufficient context windows nevertheless exhibit coherence problems well before the window fills. Reported symptoms include losing track of completed steps, repeating work, and becoming inconsistent about what has already been established. Available context capacity and effective use of it are apparently different quantities, which is one of the more practically important findings of the past year.
The no-recovery bottleneck
Perhaps the most consequential observation: current architectures are poor at noticing they have gone wrong. A human working a long task periodically checks whether the work still makes sense. Most agent architectures have no equivalent, so an error introduced at step four propagates unchallenged through step forty. The absence of self-checking, rather than the presence of errors, is what makes long horizons brittle.
Reliability as a distinct measurement
A related line of work argues that single-run success rates are the wrong measurement entirely, and that variance across repeated attempts should be reported alongside them. A system that succeeds unpredictably is a different engineering object from one that succeeds consistently, even at identical average rates, and evaluation that reports only the average conceals the difference. This connects to a broader measurement problem we examined recently in why benchmark scores have become harder to interpret.
Time as the Variable
One reframing has proven unusually productive: instead of asking what tasks a system can do, ask how long a task it can sustain.
Measuring a system’s task-completion horizon — the duration at which it succeeds some fixed fraction of the time — produces a single number that captures something benchmarks do not, and it has been tracked over successive model generations to give a sense of trajectory. Projections from this work suggest horizons extending substantially over the coming years, though projections of this kind rest on assumptions about continued scaling that should be held loosely rather than treated as forecasts.
The practical value of the reframing does not depend on the projections. It gives engineering teams a way to ask whether a given system is suited to a given task that is more informative than a capability checklist, and it makes the constraint explicit rather than discovering it in deployment.
What Is Being Tried
Research responses cluster into a few approaches, none yet decisive.
Decomposition. Breaking long tasks into shorter subtasks with verified handoffs, so that errors are contained within a segment rather than propagating across the whole trajectory. This trades away some flexibility and works best where the decomposition is natural rather than imposed.
Verification steps. Inserting explicit checks that assess whether the current state is consistent with the goal. Effective in principle; expensive in practice, and the verifier inherits the same reliability limits as the system it checks.
Checkpointing and rollback. Borrowing from distributed systems: save known-good states and return to them when something fails. Straightforward when the environment can be reverted, difficult when actions have external effects that cannot be undone.
Human checkpoints. Placing a person at intervals rather than at the end. This works reliably and is often dismissed as a failure of automation, which we think is the wrong reading. Placing the checkpoint well is an engineering decision, not a concession.
Narrower agents. Building systems that do one bounded thing rather than arbitrary long tasks. Less ambitious and, at present, considerably more likely to work.
Why This Is the Interesting Problem
Most of the capability improvements of the past several years have been improvements in per-step quality — better reasoning, better tool use, better instruction following. These are real and they compound in the wrong direction, in the sense that raising p helps end-to-end reliability far less than intuition suggests once the exponent is large.
Getting agents to complete genuinely long tasks probably requires something structurally different: architectures that monitor their own trajectories, represent goals persistently across long horizons, and can recognize and undo their own mistakes. Those are not incremental refinements of current designs, and the research community appears to be converging on that view.
It is worth noting how differently this reads from the framing that accompanied early agent systems. When agents first began taking steps toward autonomy, the assumption was that capability was the constraint and duration would follow. The evidence now suggests the opposite: capability arrived first and duration turned out to be the harder problem.
What Follows for Practice
For teams building on these systems, the research points somewhere specific.
Measure your own horizon. Determine empirically how long a task your system handles acceptably, and design within it rather than against it.
Assume errors compound. Build on the assumption that a mistake will propagate silently, because in most current architectures it will.
Put verification where recovery is still cheap. A check after step three costs little; a check after step thirty discovers a problem that has already produced consequences.
Treat human involvement as a design element rather than a deficiency — a stance that fits the broader operational picture we described in what it takes to move a working pilot into production.
The gap between what these systems can do and what they can sustain is currently the most important open question in applied AI. It is receiving serious research attention, and it has not been solved.
If you are working on long-horizon reliability and want to compare notes, I am on LinkedIn.
