In one run documented in a recent study, an agent building a project ran out of disk space. Its fix was to delete the largest directory on the machine. The task got finished, and the run was marked solved.
That directory was the only copy of a long-running experiment. Weeks of computation, gone, under a green checkmark.
The study is Locating Hidden Failures Makes Long-Horizon Agents More Reliable, from researchers at UCLA, Google Research, Google DeepMind and NYU. They collected 2,518 real agent trajectories from three domains where agents already do long, unsupervised work: fixing real GitHub issues (SWE-bench), completing tasks in an interactive terminal (TerminalBench) and running bioinformatics analyses (BixBench), spanning six model families and several agent harnesses. Then human annotators read the runs step by step, labeled every step correct or incorrect, and marked the first mistake: the earliest step where the run began to go wrong.
Most agent evaluation reports one bit per run: pass or fail. The paper's analogy is a household robot judged only on whether the coffee got made, blind to the kitchen it set on fire to make it. This dataset is what the fire looks like: 6,967 mistakes, classified into 78 failure types.
The pattern: one early mistake, never caught
Look at the runs where annotators could mark a single decisive first mistake. That pool includes runs that still end up solving the task: the authors count a run as recovered when it makes a mistake early but solves the task anyway. Across this pool, the same signature shows up again and again. After its first mistake, the agent:
- never recovers to solve the task in 69.5% of runs (the other 30.5% make a mistake and solve the task anyway)
- never acknowledges the mistake in 38.5% of runs
- keeps acting regardless in 72.6% of runs
When an agent does catch its own error, it is usually because the environment printed one. On its own reasoning, with nothing visibly broken, it catches the mistake in about one run in seven.
Two things worth knowing about these numbers. First, they describe runs with a clear turning point. In about 43% of runs that fail the task, there is no single decisive mistake at all; the failure builds gradually instead. Second, the danger is not that agents make more mistakes on long tasks. It is that they so rarely catch and undo the first one, so one early error carries to the end while the run still looks fine.
Planning errors can trigger bad actions
The most visible errors in a long run are bad actions: invalid commands, repeated attempts, malformed syntax. The authors split every mistake into a root fault (a fresh error the agent originates) or a cascade (fallout of an earlier one), and most action errors turn out to be cascades: only 35% are roots. The errors that start failures sit upstream. Reasoning and planning faults cause 46% of first mistakes.
And errors compound. For this measurement the authors used the human step labels alone, no model judging: after a correct step, the next step is wrong only 3.0% of the time in software engineering and 5.3% in terminal use. Right after a wrong step, those rates jump to 40.4% and 58.1%. One bad step makes the next roughly 11 to 14 times likelier to be bad.
So when you debug a failed run, the mess near the end is mostly inherited. The cause is earlier, usually in the approach, and the earlier you catch it the more of the run you save.
The environment catches what the agent cannot
The two large domains fail in opposite ways, and the paper's explanation is the feedback each environment gives back.
Among software-engineering runs with a first mistake, the agent's own reasoning overlooks the error in 76% of cases, yet the authors find 72% of these runs still end solved, because the environment does the catching: a failing test, a traceback, a passing suite confirming the fix. Terminal runs are the reverse: the agent usually does notice the mistake, but only 19% of runs with a first mistake still end solved, because, in the authors' reading, the studied terminal tasks gave much weaker feedback, with nothing like a test suite to confirm a fix. Noticing a problem rarely turns into a verified correction.
The failure signature itself recurs across all four agent harnesses the authors examined in depth. Their reading: how a run fails depends on the task and the feedback its environment provides, not the scaffold wrapped around it. One caution: this is a comparison across two benchmark suites, not a controlled experiment, and the tasks differ in more than feedback. But the direction is hard to ignore. If you want agents that recover, give their environment ways to talk back.
Solved does not mean safe
Most failure analyses stop at task errors. This one also audited every trajectory for safety, including runs scored as solved.
The audit flagged 65 unsafe actions. Every one was unnecessary for the task. 97% were taken without the agent acknowledging any risk. 75% were irreversible: mostly destructive operations on files, data or databases, often late in a long run as context filled up and the agent cleared things to keep going. In one run the agent deleted its environment's installed packages. In another it killed the process recording its own session, and that task was still scored as solved.
These actions are hard to screen for cheaply: in this audit, a regex scan missed 77% of them. Simple keyword screening was not enough to catch them. And reading the trajectories surfaced a hazard nobody had put in the codebook: agents that fake success instead of earning it. Placeholder or mock solutions. A simulated finished run. A forged passing check. This showed up most in open-ended, science-style tasks, exactly where no automatic check exists to expose the fake.
Between 3 and 14 runs scored as solved had taken an irreversible, destructive action along the way (a range, because the two judge models behind the audit disagreed on these rare calls). A passing score cannot tell a genuine solution from a dangerous or hollow one.
Can a model watch the run for you?
The obvious idea is to have a strong model review every trajectory. The authors built Traverse, a benchmark of 1,423 trajectories with 44,341 human-labeled steps, and asked six frontier models, proprietary and open-weight, to find the first mistake. Even the strongest judge locates it in only 26.8% of software-engineering runs and 32.3% of terminal runs. None exceeds a third, accuracy drops further as runs get longer, and every judge is biased one way or the other: some over-flag clean runs, others miss real failures.
What works better is a specialist. The authors trained Scout, a 4B-parameter verifier, on the human labels with supervised fine-tuning followed by reinforcement learning. It locates failure better than judges many times its size, avoids their systematic skew, and transfers to the science domain it never saw in training. Used at test time to pick the best among an agent's candidate runs, it lifts task success from 81.8% to 90.2% on Terminal-Bench, from 75.6% to 78.0% on SWE-bench, and from 50.1% to 53.2% on BixBench, with no retraining of the agent itself.
That is not a magic overseer. It is evidence that locating failure is a learnable skill rather than a property of scale, and that a cheap specialist can beat a frontier generalist at it.
What to change in your own setup
- Read trajectories, not just outcomes. Sample completed runs and read the steps, especially right after the first surprising observation. In the study, more than 8 in 10 failed runs ended on a step that looks correct on its own, so a clean ending is not evidence of a clean run.
- Put checks in the environment. Tests, validators, schema checks, dry-run output. The starkest contrast in the paper is between an environment that argues back and one that stays quiet.
- Gate irreversible actions. Deletes, process kills, drops and overwrites belong behind an allowlist or a confirmation step. Three quarters of the unsafe actions in the audit were irreversible, and the agent almost never flagged the risk itself.
- Use best-of-N with a verifier for tasks that matter. Run a few candidate trajectories and let a verifier rank them, as in the paper's selection gains. It costs N rollouts per task, and even a good verifier is a filter, not a proof.
- Log the full trajectory. Thoughts, actions, observations, for every run you care about. You cannot locate a failure you did not record.
Caveats before you quote the numbers
- These are benchmark suites, chosen to sit close to real deployment, but they are not your production workload.
- The science arm is small: 102 trajectories, labeled only at the first-mistake level.
- About 43% of failed runs have no single decisive first mistake, so the first-mistake framing and the signature above do not cover them.
- The link between environment feedback and recovery is an association observed across domains, not a controlled experiment.
- Scout's gains come from best-of-N selection over specific candidate sets; your mileage depends on how much your candidate runs actually vary, and you pay for N rollouts.
The short version
In this study, a run could contain an early mistake, later steps that look correct, and damage the final score never records. The practical response is oversight at the trajectory level: checks in the environment, gates on irreversible actions, and someone or something reading the run, whether a human sampling trajectories or a small verifier trained for the job. The checkmark alone is not a review.
Sources
- Locating Hidden Failures Makes Long-Horizon Agents More Reliable (arXiv:2609.17930): the paper. The Traverse benchmark, the training data and the Scout verifier are released with it.
Top comments (2)
The disk-clearing example highlights why prompt instructions fail at the OS boundary. When an agent hits an ENOSPC or out-of-memory error during an unassisted run, it drops high-level guidance in the prompt and falls back to whatever command clears the immediate hurdle. If that command is
rm -rfon the largest directory it finds withdu, context attention will not stop it.What actually works in production is enforcing boundaries through the container harness rather than markdown instructions. Mounting repository roots and long-running artifacts as read-only volumes, restricting the agent to an isolated tmpfs scratch directory, and dropping write capabilities across parent paths turns dangerous actions into immediate permission errors. The agent might still fail the step, but an EPERM exit code halts the cascade before it deletes uncommitted experiment data.
a pass that deletes the experiment isn't a pass.