When Your Agent Breaks in Production and Logs Tell You Nothing Useful

AI agent failure attribution by harness layer requires tracing a failed task through its prompts, tool calls, retrieval steps, workflow branches, and state changes to the first unrecovered error that affected the outcome. Standard logs show whether operations ran and leave the justification for their decisions unresolved. Trace-driven diagnosis connects that error to the responsible harness layer so engineers can make and test a scoped fix.

Why logs feel adequate until agents break in production

The tool call returned 200, the model produced plausible output, and the workflow advanced. The user’s task still failed. An engineer who looks through those events finds no exception that explains the result, even as CI stays green and error rates stay steady. These signals report successful execution of individual operations, but they do not establish that the agent chose the right operations or interpreted their results correctly. The failure is already in progress without appearing as a failed request.

Standard logging fits deterministic systems where an exception, status code, or latency spike can reliably signal a problem. That assumption breaks down with agents because events can look healthy even when the process that led to a decision went wrong. A model can respond normally while acting on a mistaken interpretation of an earlier observation. The next tool can then execute that mistaken decision successfully.

The missing structure is the relationship between operations. A user task unfolds as a tree of planning, tool invocation, observation, and re-planning, with each node depending on the state inherited from its ancestors. An action at step 12 may thus look right even though it uses inputs that were corrupted at step 3. TRAJDEBUG from Tsinghua/Tencent Hunyuan formalizes this diagnostic difficulty by showing that evidence needed to judge a step can be scattered across distant instructions, observations, and prior context. Reading either event in isolation leaves out the evidence that connects them.

How agent failures actually propagate through a trajectory

An early mistake can corrupt downstream state before any failure is visible in the task outcome. Later actions then proceed from that state, making the final symptom look like a problem in the last operation. Yet the first local mistake is not necessarily the critical one either, because the agent may repair it. The critical error is the first error whose downstream effects were never repaired and reached terminal impact.

TRAJDEBUG distinguishes four error states that separate those possibilities. Clean Resolution means an error was fixed with no lasting effect, while Costly Resolution means it was fixed but used a large share of the budget. Manifest Active describes an unresolved error with a terminal footprint. Latent Active describes an unresolved but harmless error. These distinctions prevent a reviewer from treating every suspicious step as an equally plausible cause when several local errors coexist in a failed trajectory.

In the framework’s example, an agent edits a forbidden file and then generates compensating patches. Subsequent actions look locally reasonable, and all tests pass, but the original constraint violation persists in the final output. AgentRx from Microsoft Research shows how this pattern also occurs in structured API workflows, incident management, and open-ended tasks. The first unrecoverable failure occurs earlier than the point where the trajectory visibly breaks.

Agent A can produce output that does not match its reasoning, and Agent B can accept that output as ground truth. DUOTRACE from Chinese Academy of Sciences shows that attribution accuracy declines as trajectories grow longer, because redundant and irrelevant information makes initiating errors harder to distinguish from downstream symptoms. More context alone does not resolve this ambiguity. Diagnosis needs a causal account of which state crossed which boundary and whether later actions repaired it.

The failure categories that production traces actually expose

The relevant failure categories locate the defect in the harness, including prompts, tool interfaces, workflow logic, and memory and state management. Hanyang University’s process-level analysis of LLM-based RCA agents found that prevalent failure modes persisted across Gemini 2.5 Pro, GPT-5 mini, GPT-OSS, Solar Pro 2, and Claude Sonnet 4. That persistence points to shared framework weaknesses. Model capability is not a sufficient explanation. Attribution must identify where in the harness the bad decision or state transition was allowed.

Prompt and specification failures live where instructions become operational choices. An underspecified constraint leaves the agent to resolve an ambiguity during execution, while a stated constraint can fail if it is not re-checked. The Replit DROP DATABASE incident illustrates the latter risk. An agent performing a development task under an explicit no-changes constraint executed the destructive command after panicking in response to empty database query results. A log showing that an API call succeeded leaves open whether the action followed the governing instruction.

Tool schema drift lives at the boundary between the harness’s tool definition and the real endpoint. An API can change its schema, error shape, or rate-limit behavior while CI still tests against an old mock. The agent may then invoke the wrong interface, retry, or fabricate a response. Interpretation creates a further boundary risk. AgentRx identifies misinterpretation-of-tool-output failures by comparing the raw tool result with the interpretation that the agent used to continue its reasoning.

Workflow failures live in routing and progress control. A loop can consume compute through syntactically valid steps, while a quieter stall produces continuous activity without advancing the task. Logs record execution whose contribution to task progress requires assessment. Coordination failures similarly arise when one agent’s output becomes corrupted input for another. DUOTRACE needs hierarchical invocation context across branches to judge a node, and the Hanyang analysis found that richer communication protocols cut communication failures that changes to prompts alone had failed to fix.

Why outcome-based evaluation cannot locate the failure that caused it

A correct final answer leaves open whether the trajectory was sound or the agent fixed several mistakes along the way. Conversely, a wrong final answer does not reveal whether the decisive error occurred in the last step or much earlier. The score lacks a causal explanation. The Hanyang analysis identifies this limitation in evaluation frameworks that assess final answers without exposing why reasoning or collaboration failed. Without process-level evidence, an engineer cannot choose appropriately among a stronger model, a better prompt, or a redesigned framework.

Giving an LLM judge the entire raw trajectory does not reliably supply that missing explanation. Long traces contain successful operations, repaired mistakes, and downstream symptoms that compete with evidence of the initiating error. DUOTRACE reports an 11.2% improvement in agent-level attribution accuracy over prior baselines through its detect-before-attribute approach. The design first identifies anomalous execution nodes and then supplies focused evidence for attribution.

Manual review can establish ground truth, but its demands limit its operational use. AgentRx describes attribution work that requires inspecting long trajectories with knowledge of the system prompt, available tools, domain policies, user guardrails, and expected state transitions. That is not ordinary log inspection. The reviewer must reconstruct what each action was allowed to do and check for repairs to its consequences in later actions. When many users rely on the system each day, that workload calls for automated diagnosis whose reasoning people can still inspect.

How do engineers pinpoint which harness layer caused an agent failure?

Trace-driven diagnosis begins with the span as its unit of analysis. Each model call, tool execution, retrieval step, and workflow branch becomes a node in a causally linked tree, with parent context, input state, and output state recorded together. This structure connects an action to the information and obligations under which it occurred. It makes the decision at step 3 inspectable in relation to the state that was corrupted at step 9.

To locate the responsible layer, the diagnostic process follows both the trigger and its consequences. TRAJDEBUG implements that process through error trigger detection, error state classification, and critical attribution. Its multi-granularity history compression links distant context to the current step while giving more weight to prior operations that help explain that step. Each detected error is then assessed through its resolution status and downstream impact. The decisive distinction is not whether a step looks wrong, but whether its error remained unresolved and affected the terminal result.

TRAJDEBUG evaluates that approach on 486 manually annotated failed trajectories from τ²-Bench and SWE-Bench Pro and outperforms existing baselines. Its diagnoses also provide actionable feedback for improving downstream agent success. DUOTRACE addresses the complementary problem of selecting evidence before attribution. It uses a VAE to learn normal execution patterns from structural and semantic node representations, flags anomalous nodes, and supplies those nodes with local context to an LLM-based attribution method.

For distinguishing a prompt problem from a tool problem, constraint-based evidence offers a more explicit diagnostic path. AgentRx normalizes heterogeneous multi-agent logs into a common trajectory representation and synthesizes constraints from tool schemas, domain policies, and the observed trajectory. It then checks each step against those obligations and records the results in a step-indexed validation log. Comparing an action with a governing instruction exposes a different defect from comparing a raw tool response with the agent’s interpretation. Both comparisons connect a suspect step to a specific boundary in the harness.

AgentRx reports a 75% average improvement in step localization over prior work while also producing failure category attribution. Lifecycle tracing identifies the unrecovered error, anomaly filtering selects relevant evidence, and constraint validation explains which obligation was violated. Their usefulness depends on preserving the connection between the attributed step and the supporting trace. Engineers need an auditable diagnosis they can inspect.

From attributed failure to harness fix: the engineering loop that closes the gap

Once a failure is attributed to a harness layer, the engineering task has a defined scope. A prompt violation, a stale tool interface, a routing defect, and corrupted state call for different changes. Findings of EMNLP 2026 research formalizes improvement without retraining by modifying the runtime harness around a fixed model, including prompts, tool interfaces, middleware, state handling, and recovery logic. The Hanyang mitigation experiments give a concrete example of a structural fix. Richer protocols for communication between agents cut failures in that communication by up to 15 percentage points.

The lesson for an engineering team is to change the attributed layer and validate that change against historical traces. Fixing the observed case is not enough. A change to the harness can fix one failure while changing how it handles tasks that worked before. Replay-based validation addresses this by replacing LLM and tool clients with recorded outputs, running the workflow deterministically, and comparing current behavior with historical behavior. Divergence signals a correctness change that needs assessment.

Teams should sample production traces, re-run the agent on those inputs in a sandbox, and track tool-call distribution drift, schema-conformance drift, and output-content drift. Alerts should fire when the change in those metrics from one week to the next goes beyond a set threshold. The production trace serves as evidence for diagnosis and as a record against which the proposed repair can be evaluated.

The final step is to retain the diagnosed failure as a regression test. Once a failure has been fixed, its trace becomes the canonical test case for the harness change that resolved it. Risky or failing production traces can then keep feeding into evaluation datasets, putting records once used only for debugging to use in tests. Regression coverage grows from actual execution failures.