Long AI Agent Runs Don't Fail on Context. They Fail on the Plan.

Give an AI agent a task that takes 10 minutes and it usually finishes clean. Give it a task that takes 10 hours, spread across dozens of tool calls and sub-decisions, and something quietly goes wrong long before the context window fills up. Long-horizon AI agents fail less from running out of context and more from losing track of the plan, and task decomposition is the fix that actually holds up.

What does long-horizon actually mean for an AI agent?#

Long-horizon means the task takes an AI agent many minutes or hours of continuous work, not one reply. METR measures this directly with a 50% time-horizon metric: the length of a task, timed by how long a skilled human would take, that a model can finish correctly half the time. That number has been climbing fast.

METR's own research, verified directly: the time horizon has been doubling roughly every 7 months since 2019, and fitting only the most recent 2024 to 2025 data suggests the doubling has sped up to under 3 months. As of the study's March 2025 publication, Claude 3.7 Sonnet's 50% time horizon measured about 1 hour. Source

Every number here is read directly from the cited paper or blog post, not a secondhand summary.

A time horizon like that is a narrower claim than it sounds. It does not mean a model works reliably for that long, only that it clears half of a specific benchmark suite at that length. The trend line has kept moving since March 2025: METR keeps a live tracker at metr.org/time-horizons, and it is worth checking directly rather than trusting a number from months ago, since the site itself flags that its current task suite makes any point estimate past 16 hours unreliable. If you have not covered the basics of what an agent actually is, our what is an AI agent primer is the foundation this post builds on.

For a small team, the practical read is not "wait for a bigger model." Whatever time horizon your current model supports, the ceiling moves out from under you every few months, so an architecture that only works because the model happens to fit the whole task in one go is one you will keep rebuilding.

Why do agents drift off-task even with a huge context window?#

Agents drift because long runs are mostly a coherence problem, not a memory problem. Andon Labs' Vending-Bench ran models through a simulated business for over 20 million tokens per run and found derailed runs, repeated errors, and tangential loops that showed no clear correlation to how full the context window was.

Entangled context is why a small early mistake can quietly reshape decisions much later in a long run.

That last part is the counterintuitive finding worth sitting with. Bigger context did not predict which runs survived. Some models managed the simulated vending machine well and turned a profit; others spiraled into what the paper's authors call "meltdown" loops they rarely recovered from, independent of how much context headroom they still had. Source

Anthropic ran a real-world version of this in its own San Francisco office. An instance of Claude Sonnet 3.7, nicknamed "Claudius," was set up to run an actual automated shop for about a month. It hallucinated a Venmo payment address, gave steep discounts to nearly everyone who asked, and at one point insisted for several days that it was a real person who would deliver orders wearing a blue blazer and a red tie. The shop lost money. Source

The lesson is not that current models are weak. It is that a single unscoped run, however capable the underlying model, has no structural way to catch its own drift. That is the gap task decomposition is built to close.

How do you actually decompose a long task into sub-tasks?#

You decompose a long task by breaking it into a graph of smaller sub-goals instead of one monolithic plan or a single step-by-step loop. A January 2026 paper on task-decoupled planning has a Supervisor split the goal into a directed acyclic graph of sub-goals, then scopes a Planner and Executor to just the active one.

The paper frames the two older approaches by their failure mode, not just their shape. Step-wise planning, deciding one action at a time, is reactive but short-sighted: it solves the next move well and walks into dead ends it could not see coming. One-shot planning, writing the full plan upfront, is the opposite problem, clean and readable but brittle the moment execution diverges from what the plan assumed. If you want the deeper mechanics of that reactive-versus-upfront split, ReAct vs Plan-and-Execute covers the control-loop version of this question in detail.

Scoping the Planner and Executor to one sub-goal at a time is what keeps a local error from spreading. Source: Beyond Entangled Planning, arXiv 2601.07577.

Both older approaches share a subtler problem: entangled context, where the agent reasons over one monolithic history spanning every sub-task it has touched. Task-Decoupled Planning fixes this by scoping the Planner and Executor to only the active sub-goal's own slice of context, so a local error stays local instead of reshaping decisions several sub-goals downstream. Tested on TravelPlanner, ScienceWorld, and HotpotQA, it outperformed strong baselines while cutting token consumption by up to 82%. Source

A related, earlier paper, Plan-and-Act, names the same planner-executor split and adds a synthetic-data method for training the planner itself, rather than assuming a general-purpose model will draft good multi-step plans for free. Source

What keeps a decomposed plan from falling apart mid-run?#

A decomposed plan survives a long run when its state lives outside any single context window: which sub-goals are done, which are pending, and what each one produced. Checkpoint that state after every sub-task completes, not just at the end, so a crash or a timeout loses minutes of work instead of hours.

If more than one of these is true, the fix is structural, not a bigger model or a bigger context window.

Scoping and checkpointing solve two different problems, and it is worth keeping them separate. Scoping, from the section above, limits how far a bad decision can spread while the run is healthy. Checkpointing protects the run when something outside your control kills the process entirely: a timeout, a deploy, a crashed worker. A DAG of sub-goals gives you natural checkpoint boundaries for free, since each sub-goal already has a defined start and a defined done state, unlike an arbitrary point in one long reasoning trace.

In practice, that state is usually a small record per sub-goal: its status (pending, in progress, done, failed), its inputs, and its output, kept in a datastore the agent process does not own, a database row or a queue message, not a variable inside the running loop. If the process dies, a new one reads the same record and picks up where the last one left off instead of starting the whole task over.

Which failure mode is actually breaking your agent?#

Most long-horizon failures fall into one of 3 named patterns. Short-sighted step-wise planning solves the next move well but walks into dead ends. Brittle one-shot planning writes a clean upfront plan that snaps the moment reality diverges from it. Entangled context lets an early mistake quietly poison every decision built on top of it.

A 4th pattern does not fit neatly into a planning bug at all: the coherence collapse Vending-Bench documented, where a model spirals into a repetitive loop for reasons that were not clearly tied to context length, and not obviously one bad decision either. Treat that pattern as a signal to add an external check, something that verifies output against the actual state of the world, rather than trusting the model to notice its own drift.

Diagnosing which pattern you are looking at is mostly a matter of reading the transcript honestly. A plan that ages badly after step 3 is brittleness. A wrong number from early in the run showing up in unrelated later decisions is entangled context. A model redoing work it already finished is the coherence pattern, and a bigger plan will not resolve that one by itself.

A concrete version of entangled context: an agent booking a multi-city trip misreads one city's time zone in sub-goal 2, and that wrong offset quietly seeds every departure time it calculates from sub-goal 5 onward, because the whole run reasons over one shared transcript instead of a fresh, scoped view per sub-goal. Scoped decomposition would have confined that mistake to the one sub-goal that made it.

Plan-then-execute, reactive, or DAG decomposition: which should you use?#

Pick the decomposition style by asking how predictable the task is and how long the run will last. A short, fully predictable task barely needs decomposition at all. A long task with independent steps fits a flat plan-then-execute list. A long task with steps that depend on each other's output needs a real DAG.

The table below lines up the 3 shapes side by side.

Three questions decide the shape: predictable upfront, dependent sub-tasks, and whether the run outlasts one context window. Every path ends at checkpointing.

If you are picking a framework rather than reasoning about this abstractly, the shape of the tool tends to match one of these strategies more than another. CrewAI's role-and-task setup has you define most of the structure upfront, which suits plan-then-execute well. LangGraph models the run as an explicit state graph with its own nodes and edges, a more natural fit for a DAG that needs to branch, checkpoint, and resume at runtime. Neither framework choice is required to get the underlying pattern right. The architecture (DAG plus scoped context plus checkpointing) is the part backed by the research above; the framework is just how much of it you build yourself versus get for free.

This is a different question from handing sub-tasks to separate agents that message each other. If you are coordinating several agents rather than decomposing one agent's own long task, multi-agent orchestration in n8n covers that hand-off problem specifically.

What should you set up this week?#

This week, take your longest-running agent and write down where it actually breaks: a bad plan, a lost thread, or a crash with no state to resume from. That answer tells you whether you need a DAG, a checkpoint, or both, and it is worth more than adding a 5th architecture to read about.

Start with the failure you can already see in a transcript rather than the one you are guessing at. If the honest answer is that it dies and loses everything, the state-and-recovery side of this matters more than the planning side, and durable execution for AI agent runtimes is the deeper guide on keeping a long run alive through a crash. If the honest answer is that it forgets the goal, start with scoping sub-goals into a DAG before you touch anything else.