Flywheel Data Quality Governance and Label Integrity

A data flywheel for LLM agents depends on label integrity as well as trace volume. Because a visible failure can originate far upstream across prompts, tools, memory, orchestration, and model decisions, annotation without causal evidence can turn production mistakes into misleading ground truth. Root-cause attribution must therefore unlock annotation, with telemetry and replay providing the evidence required to admit labels into the improvement cycle.

Why a data flywheel for LLM agents fails silently when label quality is treated as downstream

An agent returns a wrong answer, the trace receives a model-error label, and the next dataset update incorporates it. Evaluation then rewards changes that address that label, even if the original failure came from a tool contract or an upstream prompt. The pipeline completes without raising an exception. Local metrics may improve because the revised system performs better against the mislabeled example, while the originating defect remains untouched.

The flywheel moves production traces through annotation, dataset updates, evaluation, and the next deployment. At each turn, it reinforces the attribution decisions embedded in its labels. A mislabeled trace can become training signal, evaluation ground truth, or a regression baseline, so one wrong diagnosis can spread through several ways of improving the agent. None of those uses requires the attribution to be correct.

A crash exposes a broken operation, whereas a completed update can conceal a broken premise. Agent execution crosses several components, and the step where an error appears is often not the step that introduced it. Reviewing only the output therefore gives annotation a clear sign of what went wrong but may leave its cause unknown.

How multi-component agent architectures make failure origin genuinely hard to identify

LongRCA Bench shows how far apart origin and manifestation can be. Reference root-cause steps precede completion by a median of 48 recorded steps, and more than a quarter of trajectories contain over 100 subsequent steps. The decisive evidence may be far upstream. An annotator reviewing the terminal event must reconstruct how an earlier error survived later actions and checks, rather than simply identify the last incorrect action.

TelemetrySuffBench separates detecting a failure from locating its origin. OpenTelemetry-compatible and OpenInference-compatible views still allow near-perfect failure detection, but origin-step accuracy is at most a fraction of a percent. A record can make the failed outcome obvious while omitting the decision evidence needed to explain it.

HPFA, published at COLM 2026, identifies another limitation in treating trajectories as flat sequences. A later failure may depend jointly on several earlier parallel steps, so chronology alone does not expose the relevant dependencies. LongRCA Bench reports that even RCTA, its best available attribution method, recovers fewer than one quarter of reference roots exactly. Automated attribution still needs review, and these results also give no reason to expect that annotators who read raw logs without causal structure can make up for the same missing evidence just by taking more care.

The specific ways misattribution enters annotation and what it corrupts downstream

Symptom-as-cause misattribution begins when the first visible deviation or terminal failure becomes the diagnosis. Scale AI's Continual Search paper describes settling on a plausible explanation early while leaving evidence in longer traces unexamined. That shortcut can affect human annotators as well as one-shot judges. It directs prompt or tool improvements toward the symptom, while an earlier prompt ambiguity, stale memory retrieval, or changed tool schema continues producing failures.

Layer conflation creates a different routing error. A single failure label groups together how the model, prompt, tool, and orchestration layers interact without showing which one needs a change. Scale AI's root-cause attribution framing distinguishes model failures that inform post-training objectives, harness failures that guide harness design, and environment or grader issues that require benchmark repair. Collapsing those categories sends engineering effort toward the wrong component.

Cascading-error misattribution mistakes a local error for the decisive one. TRAJDEBUG establishes that some errors are repaired during execution, some remain harmless, and only some contribute to terminal failure. A regression suite built around a resolved or inconsequential error can block deployments on non-issues while missing consequential regressions. Once admitted, that label also becomes a precedent for similar traces and a basis for evaluation rubrics.

Why root-cause attribution must be treated as a prerequisite to annotation, not a post-processing step

The governance response is to change the order of work. In a label-first pipeline, annotators assign pass/fail or error-type labels before optionally adding attribution notes. Adding another field to that form does not fix the sequence if a label can still enter the dataset before its origin is resolved.

An attribution-first workflow requires the responsible layer and decisive step before a failure label can be finalized. It must also distinguish later steps that propagated the error from those that independently contributed. The label remains blocked until that account is supported. This turns attribution from explanatory commentary into an admission condition.

Continual Search pursues unresolved diagnostic evidence through successive turns. The corresponding annotation policy is to require reviewers to rule out upstream causes before assigning a root-cause label. HPFA provides a structural counterpart by comparing failed and successful trajectories through a dependency hypergraph. A similar contrastive artifact can ground review in dependencies.

Not every trace can satisfy that requirement. TelemetrySuffBench finds that some models answer every case even when there is too little origin evidence. Governance must therefore provide an explicit “insufficient evidence” outcome that routes the trace toward richer telemetry collection. A pipeline without that exit is structurally biased toward overconfident attribution.

What telemetry must capture to make attribution-gated annotation feasible

Telemetry must connect each decision to the evidence that informed it. Action names, error codes, and terminal status do not show that link. Decision content records the model's reasoning or selection, while provenance identifies the memory retrieval, tool output, or earlier observation on which it depended.

TelemetrySuffBench finds that origin-step accuracy falls to zero for every model it evaluated when decision content is removed. Removing provenance also causes large model-dependent losses. These fields serve different but linked purposes. A selection without its inputs leaves the reviewer unable to trace an inherited mistake, while inputs without the selection leave the decisive branch unexplained.

Multi-agent execution also needs records of handoffs. RCTA uses upstream instruction context at handoff points to tell apart errors that arise during execution and errors that come from another agent's instructions. Without that context, responsibility can shift to the receiving agent simply because its actions made the problem visible. The handoff record preserves the evidence needed to contest that attribution.

For teams building the flywheel, instrumentation must therefore capture the input context, retrieved memory, prompt as actually rendered, and decision content that selected the action. Hierarchical, causally linked spans support replay and root-cause analysis, but hierarchy alone is insufficient. An action-only span tree can still detect a failure. The annotation gate cannot operate unless its records preserve both the decision and its provenance.

How the harness layer is both the most common failure origin and the most frequently mislabeled one

Most agent failures originate in the harness rather than the model, yet harness failures often appear as wrong answers, hallucinated arguments, or stalled workflows. The way these failures look can lead to a model-error label. Prompts, tools, memory policies, and orchestration determine the conditions under which the model acts, so a defective condition can produce a bad output without originating in the model itself.

Tool schema drift illustrates this mismatch between appearance and origin. When a schema changes without a corresponding prompt update, the agent constructs calls against an outdated contract. The tool may still return data that does not match the expected structure. A terminal-output review sees the bad answer that results, while the causal review finds the harness mismatch that came before it.

A prompt that misrepresents the task or omits a constraint can elicit an incorrect answer even when the model reasons coherently from the instructions supplied. Orchestration loops can likewise accumulate model-level error signals as the workflow repeatedly revisits a subtask without progress. Labeling one of those outputs as the root cause directs the fix away from the controlling defect.

Harness components also change independently and interact. A prompt, schema, routing rule, or memory-policy change can break behavior elsewhere, creating failure patterns without an established annotation precedent. The engineering policy must account for that ambiguity. An explicit harness-vs-model determination must be required before finalization because it routes the correction to the responsible team.

Replay validation as the governance check that catches mislabeled traces before they enter the dataset

Replay turns a proposed attribution into a testable claim. Re-running a non-deterministic agent from scratch does not reliably recreate the original failure because tool outputs, memory states, and environment conditions may differ. Span-based replay instead uses recorded tool outputs and sandboxed side effects to reconstruct the scenario. Replay tests whether changing the attributed component removes the failure under that recorded context.

For example, a proposed diagnosis may identify a prompt that omitted the constraint violated in step 12. Replay can test that diagnosis with the prompt modified. If the failure recurs, the proposed attribution has not met the finalization standard, and the label should remain outside the dataset.

TRAJDEBUG's application studies show that diagnoses offering actionable feedback improve downstream agent success. Replay applies that relationship as a governance check by testing whether the proposed correction changes the right component before its diagnosis becomes ground truth. It should therefore be required for label finalization. Labels without replay-verified attribution remain provisional and should not update evaluation datasets, train annotators, or block deployments.

Replay also needs an abstention path. If the recorded evidence cannot reconstruct the decision state well enough to confirm or rule out the proposed cause, the trace should return for richer instrumentation. Forcing a label would replace missing evidence with confidence. That is the same failure the attribution gate is intended to prevent.

Building a label integrity governance process that treats attribution as the audit trail

Teams should use four recurring gates to protect label integrity. The first checks telemetry adequacy before annotation begins, confirming that decision content and provenance links are present at each step. Traces that fail bypass review and return to instrumentation. The second requires annotators to resolve the responsible layer, decisive step, and inherited-versus-introduced origin before assigning pass/fail or error-type labels.

The third gate tests the proposed attribution by using replay after the attributed component has been changed. Labels that cannot pass remain provisional. The fourth reopens relevant labels when a prompt, tool schema, orchestration rule, or memory policy changes, flagging attributions involving adjacent components for re-verification.

Each label that enters the dataset should keep an attribution audit trail. That record identifies the layer and step, the contrastive evidence used to rule out alternatives, and whether replay verification was completed. It makes the label challengeable as the system evolves.

Repeated attributions also deserve review across traces. When the same cause recurs, governance should aggregate the evidence into a harness-improvement recommendation instead of processing each instance as an isolated labeling task. That connects production evidence to a component-level correction. The flywheel then learns from causes that can be challenged and tested, rather than from labels whose apparent certainty conceals an unresolved diagnosis.