Production Traces as Ground Truth for Agent Quality

What benchmarks and synthetic evals measure, and where that falls short

An agent can score in the low-to-mid 90s on an internal eval suite and still fail real users on a regular basis. Mutation testing applied to SWE-Bench Verified shows why. Researchers added adversarial tests to the benchmark, built to catch solutions that pass the original suite without actually being correct. Under that harder bar, the top-ranked agent's score fell from 78.8% to 62.2%. Roughly one in five "solved" patches turned out to be semantically wrong, passing only because the original tests weren't strict enough to catch it. The model didn't get worse. The benchmark got honest about what it was actually measuring.

Most catalog metrics carry three problems baked into how they're built. Correlation is the first: on summarization tasks, overlap metrics like BLEU and ROUGE showed Spearman correlations with human raters well below 0.2 in the research introducing G-Eval, since they mostly count word overlap and never ask whether the summary is any good. Coverage is the second: when Stanford's HELM benchmark launched, most previously evaluated models had only been tested on around 17.9% of the core scenarios HELM eventually defined, so a lot of published results describe a thin slice of behavior and call it the whole picture. Contamination is the third: eval examples leak into training data and inflate scores in ways nobody catches until later, a problem serious enough that dedicated decontamination methods now exist just to fight it.

Synthetic evals in agent pipelines make all three worse, not better. Agent trajectories are non-deterministic, so the same input can take a different path through the same system on different runs, hitting different tools in a different order or pulling different context each time. A test passing once in staging says almost nothing about the range of paths that same input might take once real traffic hits it. Benchmarks and evals are not built to catch this, and pretending otherwise is the actual mistake. Once you accept that, the answer to what does catch it sits in the one place nobody can fake: the record of what the agent actually did.

What makes a production trace the honest record of what happened

Ground truth, strictly defined, means trusted reference data used to judge whether an agent's output is correct. That covers expected answers, but it also covers tool decisions, intermediate field values, and the source evidence the agent was supposed to rely on, not just the final response it handed back.

A production trace holds things no synthetic dataset can fake: real requirements from real users instead of prompts an eval author wrote while guessing at edge cases, real tool responses complete with the schema quirks and latency spikes that only show up against live systems, and edge cases nobody thought to test for because nobody could have. It also holds every intermediate belief the agent held at each step, captured as it happened rather than reconstructed later from the input and the final output alone.

That last point carries more weight than it sounds like it should. In a multi-step pipeline, one wrong route label early on can send the agent to the wrong tool, which pulls the wrong account record, and the final answer can still read as grounded and well-reasoned, because every step downstream inherited the bad reference without anyone catching it. Checking only the final output calls that a success. Reading the trace shows it for what it actually is.

Trajectory and outcome are different questions for exactly this reason. Reviewing a golden case means checking the user message, the tool calls made, the context retrieved, and the reasoning chain connecting them, all the way through to the final output. In healthcare, finance, or legal work, the scored trajectory is the audit trail proving the agent followed protocol, not just that it landed on an acceptable answer by chance. Where step order matters, path correctness decides whether the outcome can be trusted.

Most teams don't lack data here. They lack data captured at the right grain, structured enough to support reasoning about the whole trajectory instead of just poking at individual steps. Traces become datasets, datasets become experiments, experiments become shipping decisions, and none of that holds up if the traces feeding it weren't built with that pipeline in mind from day one.

What you can read from a trace that you cannot read from any other source

A well-built trace supports evaluation at three separate levels. End-to-end asks whether the task succeeded. Trajectory asks whether the path there was sound: right tools, right order, right arguments. Component asks which specific piece, a retriever, a tool, a sub-agent, actually broke.

Certain metrics only become visible at the trajectory level. Tool correctness asks whether the right tools got picked at the right moment. Argument correctness asks whether the parameters passed to those tools were actually right. Step efficiency asks whether the agent looped on something it didn't need to, or wandered down a dead end before recovering. Plan adherence asks whether the agent stayed aligned with the original goal as new tool outputs came in, or drifted somewhere in the middle.

Tool-level monitoring works as an upstream quality gate on its own. Schema violations and malformed arguments appear in execution traces, so a team watching traces catches which tool calls degrade across runs, sometimes tied to something as concrete as context length: as context grows, schema compliance can slip, and that slip is visible in the trace before it becomes an incident anyone outside the team notices. Output validation policies built on that visibility shift enforcement from cleanup after the fact to catching the problem mid-run, a distinctly different job.

Traces also reveal failure modes nobody wrote a metric for yet. That's the long tail no synthetic dataset can anticipate, because nobody imagined it. It just happened. Paired with periodic human review of a sample of traces, this keeps eval scores honest as the agent's behavior drifts, instead of letting a metric quietly go stale while the system underneath it keeps changing.

Why failures surface at a different layer than where they originated

Attribution is hard in agent systems for a structural reason. A weak plan or a bad early assumption cascades through every step that follows, so by the time a failure becomes visible, it's often many steps removed from its actual cause. Long, largely autonomous runs make this worse: the failure hides deep in the trajectory instead of announcing itself where it actually started. With retrievers, tools, planners, and sub-agents all feeding one run, an end-to-end score tells you something broke, but not which of those components broke it.

Most observability tooling can replay an execution trace step by step, and that's useful, but replay alone doesn't find root cause, and it doesn't turn a diagnosis into a fix. As agents take on longer-horizon tasks, the execution logs grow correspondingly massive, while the causal information that actually explains a failure stays sparse, scattered across distant steps and disconnected from the point where the failure surfaced. Root-cause attribution, at that scale, is a search problem before it's anything else.

Multi-agent systems add another layer of difficulty on top. When agents act concurrently or semi-independently, causal links between their actions become entangled, which produces exactly the kind of weak observability and blurred responsibility that makes attribution hard to even define, let alone automate. Scrolling through a trace looking for the obviously wrong line won't fix any of this. What it calls for is structured attribution: tracing a symptom backward to the specific agent and step whose correction would most likely have stopped the failure before it started.

How structured attribution connects a failed trace to a specific harness layer

One framework built specifically for this, described in research on closed-loop agent debugging (Zhu et al., arXiv:2607.18754), runs a four-stage loop: detect, attribute, recover, rerun. Detection catches an observable failure and matches it to a known failure mode. Attribution traces that symptom backward through the trajectory, using a global view of the run, structure-guided investigation, and cross-examination of competing explanations, to find the step most responsible. Recovery turns that diagnosis into a concrete, specific retry instruction instead of a vague "try again." Rerun checks the fix against the original failed trace, so it gets validated against the exact failure it was meant to solve, not some newly generated stand-in.

Closing that loop, instead of running detection and correction as separate steps that never talk to each other, produces a measurable gain. On the GAIA benchmark, the closed-loop method repaired 13 of 73 failed tasks in a single rerun, against 4 to 6 repaired by three decoupled self-correction baselines run for comparison, lifting overall task accuracy from 55.8% to 63.6%. Correction applied without a grounded diagnosis tends to fix something. It just doesn't reliably fix the thing that was actually broken, which is a costly distinction to miss.

Attribution itself is measurable, and it's still a hard problem, nowhere close to solved. On the "Who and When" attribution benchmark, the same method reached 28.8% exact accuracy identifying both the responsible agent and the responsible step, against 21.7% for the strongest single-pass baseline tested alongside it, a real improvement over the alternative. That's a real improvement over the alternative. It's also a reminder that most failed traces still resist confident attribution, so treat the number as a floor, not a finish line.

A separate line of research proposes attributing failures to specific layers in an agent's harness. The execution environment and sandbox governs how safely and reproducibly the agent can act. The tool interface covers how tools get discovered, described, selected, and invoked, including the schemas and error messages that come back. Context and memory covers what the model actually sees at each step, from context window contents to session state to retrieved evidence to anything carried across runs. Lifecycle and orchestration covers the think-act-observe loop itself: retries, task-state tracking, coordination across sub-agents, and when a run ends. Observability asks whether traces, logs, tool calls, and cost data get captured at a grain fine enough to diagnose the problem. Verification and evaluation covers readiness checks, validation of intermediate steps, and regression testing against prior behavior. These layers, taken together, cover the principal sites where fixable failures originate.

Naming these six layers matters because many self-improving agent systems never pin down where in a failed trajectory the responsible evidence sits, or which layer of the harness produced the bad behavior. That vagueness produces fixes that are too broad, too indirect, or aimed at the wrong target. The same research describes compiling raw traces and harness artifacts into what it calls a harness-aware intermediate representation, built specifically so the layer responsible for a failure becomes something a person, or another system, can actually inspect and act on.

Why the harness is almost always the right place to intervene

The harness, in current usage, means something a lot bigger than a prompt template. It covers workflow design, evaluation, permission controls, and persistent state management, and it sits closer to runtime and software system design than to prompt engineering, as Lilian Weng described the shift on her blog.

Broken into pieces, the harness is where most fixable behavior actually lives. Prompts encode the behavioral rules and reasoning steps an agent follows. Tools expose outside services through action schemas that define what the agent can and can't touch. Memory stores prior observations and reusable strategies within a session and across sessions. Skills package reusable procedures into modules the agent calls instead of rebuilding from scratch every time. That last shift, from generating task-specific behavior fresh on every run to assembling it from pre-validated pieces, shrinks the surface area where new failures can start, since a validated skill isn't getting reinvented and re-broken every time it's called.

The model is not where the money is, and December 2025 made that plain. Meta announced an acquisition of Manus for a substantial sum (later blocked and unwound). Manus runs on foundation models from other providers, including Anthropic and Alibaba's Qwen, so the model was never the asset on the table. Meta was paying for the harness: Manus iterated heavily on its agent harness, and those architectural improvements drove gains in reliability and task completion independent of which underlying model was doing the reasoning.

That pattern doesn't generalize well for most teams, though. A widely cited estimate puts the share of AI agent projects that never reach production at around 88%, and a harness too fragile to survive real use causes most of those failures. Limiting what an agent sees at each step to what it actually needs for its current sub-task, rather than exposing the full context window, is a recognized approach to reducing informational overload. Nobody hands that setting down from a model provider. The context and memory layer is a dial the engineering team controls directly, and tuning it is harness work, full stop.

For an engineer staring at a failed trace, the useful question is which harness layer actually caused the failure, and what specific, reviewable change to that layer fixes it. It's which harness layer actually caused the failure, and what specific, reviewable change to that layer fixes it.

Closing the loop: from a failed trace to a validated, shippable fix

Teams that treat this seriously tend to converge on the same closed loop. Offline eval feeds a CI gate. The CI gate feeds evaluation of live production traces. Trace evaluation feeds an error feed made up of runs that failed or scored badly. The error feed feeds optimization work aimed at the harness. That optimization ships back through CI before it ever touches production again.

That loop runs on a three-level eval structure doing different jobs at different speeds. Assertion-based unit tests run on every commit: fast, deterministic, good at catching obvious regressions before they ship. Trace-based evaluation using an LLM as judge runs slower, on curated datasets, and handles judgment calls a simple assertion can't make. Continuous production monitoring runs on every real session, scores it, gates anything risky, and feeds failing runs straight back into the offline dataset so the next round of testing already knows about them.

Replay belongs in this loop as a regression gate, not just a debugging convenience. Once a bad trace turns up, the specific spans that produced the bad response get identified, the failing case gets added to a permanent scenario library as a standing regression test, and only after the harness fix lands and the full regression suite runs clean does the change ship. Scores have to improve, full stop, and nothing that worked before gets to quietly break in the process.

Mature teams settle into a steady cadence: regression tests on every pull request, a broader persona sweep run nightly, and live tracing running across all production traffic. Offline testing catches the regressions that should block a release. Live tracing catches the long tail of behavior no test author, however careful, ever thought to write down in advance.