How to find the root cause of a failed long-horizon AI agent run in 2026

Find the root cause of a failed long-horizon agent run by reviewing an evidence-backed error lifecycle—not by choosing the first bad-looking step or final symptom. Preserve the earliest suspected wrong commitment and the evidence that contradicts it, determine whether later work repaired it or merely worked around it, then connect the remaining candidate to the terminal failure before changing the harness.

First contain the run and preserve its state; Bonfire's AgentOps incident-response playbook covers that boundary. Then decide which trace event deserves the fix. In a long-horizon run, those are not reliably the same thing.

486

manually annotated failed trajectories in TrajErrBench

3 stages

trigger, lifecycle state, and causal-candidate review

A failed trace can contain several kinds of mistakes

The TRAJDEBUG preprint frames critical-error detection around a practical distinction: a failed trajectory can include local errors that were repaired, errors with no meaningful downstream effect, and later symptoms of an earlier failure. Its goal is to identify the earliest error causally linked to the final failure—not simply the earliest error in time.

This table is Bonfire's AgentOps Hardening review record. The fields are deliberately modest: they make the diagnosis inspectable rather than asking a model to narrate certainty after the fact.

Start with a contradiction, not an intuition

TRAJDEBUG's first stage detects an error trigger as a wrong commitment grounded in a conflict with task instructions, trajectory history, environment feedback, or the step itself. The paper requires explicitly citable evidence for both the allegedly wrong commitment and its reference; triggers without that support are discarded.

For each suspect transition, capture:

1. What the agent committed to—plan, inference, action, or verification result.
2. The exact reference that conflicts with it.
3. Where that reference was available to the agent or harness.
4. Why the contradiction is relevant to the terminal failure.

Group repeated symptoms before counting failures

One mistaken assumption can recur in planning, tool use, and verification. TRAJDEBUG clusters triggers that violate the same reference object so repeated manifestations are treated as one continuing error instance rather than multiple independent errors.

Give every candidate a stable review ID and attach later manifestations to it. Your agent observability dashboard should make the run state, tool results, retry history, and evidence link visible beside that candidate. The dashboard does not need to decide causality; it needs to make a human's decision falsifiable.

Separate a clean repair from an expensive or incomplete one

The preprint separates whether an error was resolved from whether it left a terminal footprint. Its examples of a footprint include an irreversible state change, a wrong commitment reflected in later or terminal state, and recovery that consumes enough of the trajectory's budget to matter.

1. Cleanly resolved: a later step explicitly replaces the bad commitment with evidence. Keep it for learning, but do not promote it automatically as the root cause.
2. Costly recovery: the agent corrects the problem but spends material time, budget, or opportunity doing so. Record it as a reliability issue even when the terminal task succeeds.
3. Still active: the bad commitment remains relevant to later reasoning, state, or side effects. It belongs in the causal candidate set.
4. Terminally material: evidence connects the unresolved error—or its recovery debt—to the final failure. Escalate it for human review before making a corrective change.

These labels and their escalation policy are Bonfire guidance, not a threshold supplied by the paper. Choose review thresholds from the workflow's risk, side-effect surface, and recovery budget.

Review causal candidates against the final failure

TRAJDEBUG's final stage selects among retained candidates using each candidate's origin step, state label, footprint channel, and supporting evidence. The paper explicitly warns that an earliest-candidate rule is insufficient: chronological order alone does not establish responsibility for the terminal failure.

• Would the terminal failure still be plausible if this candidate had not happened?
• Is the link to the outcome recorded in the trace, or merely inferred from timing?
• Did a later repair actually retract the relevant commitment, state, or side effect?
• Is another active candidate supported by stronger direct evidence?

When the outcome is consequential, route an uncertain answer to a human reviewer. Google's SRE guidance describes a postmortem as a written record of an incident's impact, mitigation or resolution actions, root causes, and follow-up actions; it emphasizes understanding contributing causes rather than blame allocation.

Use automation to narrow the review, not to certify cause

TRAJDEBUG evaluated its framework on TrajErrBench, a set of 486 manually annotated failed trajectories drawn from τ²-Bench and SWE-Bench Pro. That is promising evidence for the lifecycle framing, but it is not proof that automated attribution will transfer to your tools, policies, or runtime.

The authors state two important limits: the framework relies on LLMs for error interpretation and final attribution, and false negatives in earlier trigger detection or state classification can exclude the true critical error from the candidates. Use an LLM to assemble candidate records, retrieve contradictions, and summarize a long trace. Keep the authority to label root cause—and to trigger a production change—with a reviewer who can inspect the evidence.

Turn the diagnosis into a safe next action

Once the failure-responsible transition is evidence-backed, choose a change that matches the mechanism:

• A missing or ambiguous constraint calls for a clearer contract or pre-action check.
• A stale observation calls for an explicit validity boundary or re-fetch before action.
• A repeated failed repair calls for a stop condition or different recovery lane.
• A harmful side effect calls for containment and reconciliation before any replay.

Use the agent workflow recovery plan to decide whether the safest next move is a bounded resume, repair, or stop. The postmortem is complete only when its proposed control can be tested against a representative failed trace—not when it produces a persuasive story.

Caveats

• TRAJDEBUG is an arXiv v1 preprint submitted on August 6, 2026; it is not peer reviewed.
• Its benchmark and results do not establish a universal error taxonomy, severity threshold, or root-cause automation policy for production agents.
• An evidence-backed candidate is still not a production root-cause verdict when a missed trigger, ambiguous trace, or high-impact side effect is possible.