When a coding agent run fails, most developers experience this at the end: the output is wrong, the test doesn't pass, the feature is half-built. The instinct is to attribute this to whatever happened last — the final tool call, the last file modification, the context it ran out of near step 180 of 200. The July 2026 paper "Failure as a Process" mapped 3,843 actual CLI agent trajectories and found the opposite. Failures are typically locked in during the first third of execution. What you see at the end is just when you notice.
That's not a subtle finding. It changes where intervention is useful.
What the Paper Actually Measured
Researchers from University of Maryland, CMU, and ETH Zurich collected 3,843 execution trajectories generated by seven frontier models across three coding-agent scaffolds — OpenHands, MiniSWE, and Terminus2 — running on Terminal-Bench. After filtering to 1,794 complete trajectories with sufficient length for annotation, they manually labeled 63,000 execution steps.
The annotation framework treats failure as a timeline rather than a verdict. Each trajectory is analyzed across three phases: the onset, where the first decisive error is committed; the evolution, where that error compounds into downstream mistakes; and the unrecoverable point, where the trajectory has diverged far enough from a valid solution path that no sequence of remaining steps would produce a passing outcome.
Most empirical agent research uses a binary signal: the task either passed or failed. That's useful for benchmarking models but not for understanding what to do about it. If you only know "this run failed," you know nothing about when to have intervened. The process-oriented framework is designed to answer the question that matters for working developers: at which step did this become unloseable?
The Failure Pattern
The paper's central finding is that failures are predominantly epistemic in character. The agent reasons from wrong premises. It misreads the project structure, draws incorrect inferences about what the task requires, or constructs a solution plan that's wrong before it begins executing — and then executes faithfully against that wrong plan for the rest of the trajectory.
This is the failure that's hardest to catch by reviewing output. If the agent is coding correctly to an incorrect understanding of the problem, the code it produces often looks reasonable. The syntax is clean. The tests it writes pass for the wrong behavior. The error is invisible until you run the full evaluation or try to actually use what it built.
The timing: onset events cluster in the early steps. The evolution phase — where the compounding begins — is usually well underway by the midpoint. The unrecoverable point arrives before most trajectories end. On runs that failed, the median unrecoverable point was in the first 30-40% of total execution steps.
The consequence is direct: if you're reviewing the final output of a 200-step agent run, you are looking at a failure that was sealed in steps 50-80. Nothing in the last 120 steps caused it. Nothing you could have done in the last 120 steps would have fixed it. The recovery window closed while the agent was still running.
Why Binary Evaluation Masks This
The reason this went unmeasured for so long is that the standard evaluation signal — pass/fail at end of trajectory — is actually well-suited for comparing models but poorly suited for informing intervention strategy. If you want to know which model to use, pass rate at task completion is the right number. If you want to know when to interrupt a running agent, it tells you nothing.
There's also a psychological dynamic here. Watching an agent run while you're coding feels like supervising. You see tool calls, file diffs, shell commands. The activity creates an impression of ongoing engagement. The research suggests this impression is misleading in a specific way: the consequential phase — the early epistemic errors — often looks identical to the setup phase of a successful run. You can't tell from watching the tool calls in steps 20-40 whether the run is already off the rails.
Most developers don't want to interrupt a run that looks like it's going fine. The cost of a false positive intervention (you stopped a run that was on track) feels high. The research reframes this: the expected cost of not intervening — waiting for the unrecoverable point to become visible — is almost always higher.
AgentForesight and What's Coming
Concurrent work is trying to make the unrecoverable point visible in real time. AgentForesight (May 2026, arxiv 2605.08715) evaluates each trajectory prefix as it unfolds — not the full run, but the steps so far — and flags the decisive error at the step it commits. The goal is to open an intervention window before the failure is locked in, rather than after.
This is a harder problem than offline annotation. When you're annotating a completed trajectory, you have the full context; you know what came next and what the outcome was. A real-time system has to identify the onset of an epistemic failure from partial information, while the run is still in progress. AgentForesight's results are early and the false-positive rate is not yet low enough for production deployment without a human in the loop. But the direction is clear: intervention tools will be calibrated to the unrecoverable point, not the final output.
That shift in orientation has implications for how you think about your own supervision practices today, before the tooling catches up.
The 91% Number from the Same Month
The misalignment paper published the same month (May 2026, Notre Dame/Vanderbilt/Google, 20,574 real-world sessions) reported a number that connects to this directly: 91.49% of visible resolutions still required explicit user correction.
That's nearly universal. When developers noticed a problem and resolved it in the session data, almost all of those resolutions were manual corrections rather than agent self-recoveries. The agent flagged the issue itself or autonomously recovered in fewer than one in ten cases.
Taken together, the two papers are telling you the same thing from different angles. The trajectory paper says failures become irreversible early. The misalignment paper says when developers do intervene and fix things, they're almost always doing the correction manually. Which means the practical question is not "will the agent fix it?" but "when will I notice, and will it be in time?"
The answer the trajectory paper gives is: you will usually notice at the end, and by then it won't be.
Where to Put Your Attention
There's no software that tells you, in real time, that your current agent run locked in a failure at step 42. AgentForesight is close but not production-ready. For now, the practical response is behavioral.
One pattern that follows from the trajectory research: for any agent run longer than about 50 steps, a checkpoint somewhere in the first third is more valuable than any review you do at the end. What you're looking for at that checkpoint is epistemic alignment — does the agent's working model of the problem match your actual intent? Not "is the code right so far" but "is it solving the problem I specified, or a plausible-sounding adjacent problem I didn't specify?"
This is harder to verify quickly than reviewing a diff. You're checking the premises, not the output. The most reliable approach is to look at what the agent has concluded about the task, not what it has produced. If it has documented its plan or reasoned about the approach in its early steps, that's where the failure will be visible — before the code that implements the wrong plan makes it harder to see.
At xeve, session tracking captures when developers switch from waiting on an agent to actively reviewing or correcting. The gap between those two events — the time between "agent running" and "developer engaging with output" — is almost always too long relative to what the trajectory research implies is useful. The correction happens at the end of the run. The unrecoverable point was in the middle.
Knowing that the failure window closes early is the beginning of an intervention strategy. The hard part is building the habit of looking there instead of at the end.