2026-08-06
An RUC-led survey frames long-horizon agents as harness-model co-evolution and cites METR: frontier task horizons double every 4-6 months.
"Long-horizon agent" has become a buzzword whose meaning keeps blurring. Long-context, long-running, autonomous, and self-evolving are used almost interchangeably, though each names a different facet. Prior surveys tend to fix on one component (memory, context engineering, the harness, self-evolution, or agentic RL); each is a real piece, but none says what a long-horizon agent is or how to build a reliable one end to end.
This matters because long-horizon competence is becoming the practical line for delegating real work. Citing METR, the paper notes that the tasks frontier agents can handle unaided have climbed from seconds to hours; frontier coding agents already run for hours on a single project, and GLM-5.1 is reported to sustain independent execution on one task for up to eight hours.
Why is the long horizon hard? Three failure modes recur. Goal drift and compounding error: over thousands of steps an agent slowly diverges, and small per-step errors accumulate. Context rot and context-limit pressure: once working context crosses a utilization threshold, performance degrades abruptly, or the agent gives up early and declares half-finished work done. Sparse, delayed, irreversible rewards: many tasks pay off only at the end, so intermediate decisions get almost no signal, and the longer an agent acts the more likely it takes an action it cannot undo.
The central claim: long-horizon agency is a system-level property of the co-evolution of two pillars, externalized harness engineering and internalized model optimization, not of the foundation model alone.
Formally, Agent = πθ ⊕ H, where πθ is the base policy and H is the surrounding runtime (loops and workflows, context and memory, tools and skills, orchestration, hooks, verification). ⊕ is runtime coupling: H closes the action, observation, memory loop around πθ. The system is cast as a POMDP, with reward typically sparse and delayed, so credit for the decisions that actually matter must be inferred from a single terminal signal, the long-horizon credit-assignment problem.
Using "how far execution must stretch beyond one context window" as a proxy for dependency burden, the paper sorts tasks into three nested levels, each paired with a capability:
| Level | Span | Capability required |
| H1 intra-context | minutes, one window | C1 interactive reasoning: many interdependent steps into one trajectory |
| H2 cross-context | hours to days, outgrows a window | C2 state and memory: compress, externalize, checkpoint, resume |
| H3 cross-task streams | lifelong, open-ended | C3 experience accumulation: reusable skills, continual improvement |
The levels nest, so an H3 agent must still clear C1 and C2 inside every task. Control-surface evolution splits into three stages: prompt engineering (2020 to 2023), context engineering (2023 to 2025), and runtime harnesses (2025 onward). The whole survey runs over six perspectives: Foundation, Evolution, Harness, Optimization, Application, Frontier.
As a survey, its results are an attribution framework plus an empirical trend, with the hardest numbers from METR's "50%-task-completion time horizon," the human-expert time of tasks an agent completes with 50% reliability.
| Window | Doubling time | Note |
| Full period (stitched, from 2019) | about 196.5 days (6.5 months) | early models on TH1.0, later on TH1.1 |
| 2023 onward (TH1.1) | about 130.8 days (4.3 months) | hints at acceleration, but methods differ |
By May 2026 the frontier had grown from seconds (GPT-2) to about twelve hours for Claude Opus 4.6 and at least sixteen hours for an early Claude Mythos Preview, nearly four orders of magnitude. Sixteen hours is where METR calls its current task suite unreliable, so estimates past it carry real uncertainty.
On applications and evaluation, the paper sorts long-horizon agents by their interface with the environment into five forms (software engineering, information seeking, computer use, multimodal, general-purpose) and consolidates about eighty benchmarks and systems, deliberately weighted toward multi-hour autonomy: MLE-bench, PaperBench, Terminal-Bench, OctoBench, and METR itself. Its stated position: a score is a joint product of model, harness, and training recipe, not the model alone.
For practitioners, the main payoff is an attribution vocabulary. When an agent's score jumps, the framework forces the question: did the gain come from a stronger policy, a better runtime harness, or a change in data or evaluation? The bidirectional migration between harness and weights has a direct corollary: a fair share of long-horizon capability can be bought by improving the runtime (smarter loops, memory compression, external verification, hooks) without retraining. The H1/H2/H3 ladder tells you which capability class your task actually demands. Two positions are worth keeping: environment construction, not model scale, is the rate-limiting step for the next phase; and the harness, not the model, is the principal alignment and privilege surface for production agents, with model-side alignment necessary but rarely sufficient.
The co-evolution and harness-optimization framing is an organizing lens, not a taxonomy shown empirically to beat alternatives; H1/H2/H3 is a human-chosen operational axis, and the paper itself calls the time ranges descriptive rather than definitional thresholds.
The METR doubling series is stitched from two methods (TH1.0 early, TH1.1 late), so the "acceleration to 4.3 months since 2023" is only a hint; the authors say it cannot be taken as confirmed acceleration. Anything above sixteen hours is unreliable, so figures like Mythos Preview's "at least sixteen hours" deserve skepticism. More fundamentally, the trend captures that horizons are growing but not why, and cannot separate gains from policy, harness, or their co-evolution, which is the very attribution problem the survey wants but fails to close.
On scope, it does not aim to cover general LLM agents, memory, or RL in full, only the parts that bear on horizon; the benchmark table is representative rather than exhaustive; and the references mix product docs and open-source implementations (Claude Code, Cursor, Doubao) with peer-reviewed work.