Why Your Agent Finishes the Five-Minute Task and Fails the Four-Hour One

An agent that edits one function and an agent that owns a four-hour migration are not solving the same problem. The second contains more decisions, more tool calls, more state changes, and more chances for a mistake to slip through unnoticed.

That gives you a better delegation question than "can the model code?" Ask how long the task would take a skilled human, and ask what happens after each intermediate step.

What is a task-completion time horizon?

It is the human-estimated task duration at which an agent's fitted success curve crosses 50% on a defined benchmark suite. METR estimates each task's duration from how long a skilled human takes, then fits a curve of success against that duration.

Read the definition carefully, because it is narrower than it sounds. A two-hour horizon does not mean an agent completes every two-hour task, and it does not mean the agent can run unattended for two hours. It means the fitted curve crosses 50% at that benchmark duration.

A 50% result is a coin flip. It is not an autonomy licence, a service-level objective, or a recommended timeout.

How fast is the horizon moving?

Quickly, and on a fairly clean exponential. METR reports that "the length of tasks models can complete is well predicted by an exponential trend, with a doubling time of around 7 months," measured across roughly six years.

Those per-model figures come from METR's time-horizons dataset, and the trend line is the finding rather than any single row. METR also reports a faster doubling, closer to four months, across the 2024 to 2025 segment. That is an observed rate over one window, not a law, and any calendar-date forecast built on either rate is a projection rather than a measurement.

The table tracks a benchmark. It is not a lookup table for how long you may leave an agent alone, because task composition, scaffolding, tooling, and evaluation method all move the result.

How long can an agent work before reliability falls?

METR's sharpest finding is the contrast at the two ends: "current models have almost 100% success rate on tasks taking humans less than 4 minutes, but succeed <10% of the time on tasks taking more than around 4 hours."

That gap is the practical content of the whole idea. Short-task performance tells you almost nothing about long-task reliability, so a demo of an agent nailing a quick fix is not evidence about the migration you were hoping to hand it.

A short task gives the agent a narrow trajectory: inspect, change, check, stop. A four-hour task asks that pattern to survive repeated planning decisions and external effects, where one wrong assumption can alter the state everything afterward depends on.

Why do long tasks fail structurally?

Because a longer sequence simply contains more opportunities for an error to enter and propagate. The agent does not need to get less intelligent at hour three for whole-task success to collapse.

Toby Ord's half-life analysis gives the cleanest intuition. Model each task as a chain of steps where failing any one fails the whole thing, assume a roughly constant chance of failure per unit of task time, and the exponential decline falls out: an agent at 50% on one-hour tasks lands near 25% on two-hour ones. Local competence stays flat while end-to-end success drops.

Worth knowing that Ord himself has since updated this. In a February 2026 note he reports that agents likely do not follow a constant hazard rate, and instead show a declining hazard rate on longer tasks, meaning an agent that survives the early part of a task is somewhat more likely to keep going than the simple model predicts. Treat constant hazard as the intuition that explains the shape, not as the settled mechanism.

Either way the engineering conclusion holds: reduce the number of dependent steps between checks.

How is this different from context rot?

They are separate mechanisms and teams conflate them constantly. Context rot is accuracy degrading as the active context grows. Long-horizon failure is success declining as dependent actions accumulate. A task with short prompts can still fail because it contains too many linked steps, and a single-step task with an enormous context can fail the other way.

Run-to-run variance is a third axis again. Reliability as a distribution over repeated runs asks how often the same task succeeds across attempts. Task length asks how success changes as duration grows. Diagnose them separately, because the fixes differ: better retrieval for the first, fewer steps between checks for the second, more trials for the third.

Which tasks should you delegate first?

Ones with a bounded objective, a small state surface, reversible effects, and an automated check. Short implementation changes, isolated test additions, documentation edits, and narrowly scoped investigations fit that profile far better than open-ended ownership.

Human duration is only the first filter. Two thirty-minute tasks can carry very different risk: one is independent edits with a clear test suite, the other depends on undocumented state and has an irreversible side effect.

Four questions before delegating:

• Can the finish condition be checked by a machine?
• Can each intermediate result be inspected without reconstructing hidden context?
• Can a failed step be retried or reverted safely?
• Does the task stop before its measured reliability boundary?

A yes to all four does not prove safety. It identifies work with a tractable control surface.

How do you decompose a task longer than the horizon?

Into stages that each produce a durable artifact and a verifiable handoff. Decomposition converts one low-confidence trajectory into a series of smaller decisions where a check can stop an error before it propagates.

A useful unit is not "work for an hour." It is "inspect these files, propose a patch, run these tests, return the diff and the test output." That has an input boundary, an output boundary, and a check, and the next stage receives the artifact rather than the entire hidden history.

For a migration, the stages might be inventory, plan, implementation, test, and review. Implementation should not also decide scope, invent the rollback, and apply the production change. Require explicit artifacts at each boundary, and keep irreversible actions behind an approval.

The answer is not automatically a multi-agent system, either. More agents add coordination surfaces of their own, and the case against splitting applies whenever decomposition introduces more coordination than independent work. Staged delegation to one agent is usually the smaller change. If a stage needs expertise your team lacks, a packaged expert from a marketplace such as Askpert is one way to fill it, though the rule is unchanged: define the stage, inspect its output, and keep a human decision point wherever the consequence is hard to reverse.

What does this change about delegation policy?

It turns a binary capability question into a risk-adjusted boundary. Instead of asking whether an agent is good enough, track human-estimated duration, action count, reversibility, evaluator quality, and the cost of a bad handoff.

A workable policy sorts work into three buckets. Direct delegation for short, checked, reversible tasks. Staged delegation for longer work with clear artifacts. Human-led execution where evaluation is weak, state is hidden, or consequences cannot be undone.

Then make it empirical. METR supplies an external measurement, but your repository, tool set, permissions model, and evaluator all move local success rates, so measure repeated stage outcomes in your own environment before widening the boundary.

The decision is not whether an agent can run for four hours. It is whether any unchecked dependency in that four-hour task deserves four hours of unsupervised execution.