Turning Agent Failures into Tests and Harness Fixes with NVIDIA NeMo

When AI Agents move from demo prototypes to production environments, how a team handles failures directly determines its iteration efficiency. The approach proposed in NVIDIA's official developer blog is to systematically distill production failure evidence into a prioritized issue list and custom evaluation sets, then feed those back into improvements to prompts, tools, models, memory, skills, and harness code.

Why Agent Failures Need to Be "Engineered"

Traditional software testing has deterministic inputs and outputs, whereas an Agent's behavior is jointly determined by model reasoning, tool calls, and context memory—so failures are often sporadic. If failures are treated merely as one-off bugs to be fixed by hand, the same problem will recur in production. The core argument of the NVIDIA blog is: failure is not the endpoint—it is the raw material for test assets.

By collecting production failure evidence and converting it into reproducible test cases and evaluation criteria, teams can establish a sustainable quality loop instead of constantly firefighting.

Why Agent Failures Are Sporadic

Unlike traditional software, an Agent's output is not produced by deterministic code paths but sampled by the model given a context. Temperature parameters, context length, subtle differences in tool return values, and even different orderings of the same input can all push reasoning down different branches. As a result, the same Agent facing similar tasks may succeed once and fail once—failures are probabilistic rather than deterministic.

This characteristic has two consequences: first, single-instance reproduction is difficult, and engineers cannot easily locate root causes with breakpoints the way they debug ordinary bugs; second, sporadic failures are easily dismissed as "bad luck" and ignored, until they accumulate into systemic risk in production. That is precisely why failures must be treated as statistical samples rather than isolated events—only by collecting enough failure evidence and recording complete context can sporadic problems become analyzable, reproducible test assets.

From Failure Evidence to a Prioritized Issue List

The blog's first step is to turn failures from "verbal descriptions" into "structured issues." Production evidence includes the context in which the failure occurred, the input at the time, tool call records, and the deviation between the final output and expectations. Once aggregated, teams can rank priorities by impact scope and reproduction frequency, distinguishing high-frequency critical issues from long-tail edge cases.

The value of this layer is that it grounds discussions in data. Engineers no longer need to judge "how serious is this bug" by gut feeling—they can directly reference real production data to make trade-offs.

Custom Evaluations: Making Fixes Verifiable

The more critical piece of the NVIDIA approach is building custom evaluations. By converting each category of failure sample into an evaluation item, teams gain a repeatable checking mechanism: after modifying prompts, changing tool-calling strategies, or adjusting the model or memory mechanisms, running the evaluation set shows whether the fix works and whether it introduces regressions.

The improvement dimensions covered by these evaluation sets are explicitly listed in the blog, including prompts, tools, models, memory, skills, and harness code. In other words, failure-driven testing targets not just the model itself but the entire Agent runtime framework.

How Custom Evaluations Differ from General Benchmarks

General benchmarks (such as the task sets used in various Agent leaderboards) measure a model's average capability in standardized scenarios; their questions are public and their distributions fixed, so they can hardly reflect the specific failure modes within a given team's own business. Custom evaluations, by contrast, are check items reverse-engineered from one's own production failure samples: each corresponds to a real error that actually occurred, with explicit inputs, expected behavior, and judgment criteria.

Their value lies in two things: targeting, since they directly test whether edge scenarios that once broke have been fixed; and regressability, since the evaluation set can be run repeatedly to quickly detect regressions after any prompt, tool, or model change. In practice, custom evaluation can use exact matching, rule-based validation, or a model as judge (LLM-as-judge)—but whichever method is used, the key context from the failure samples must be fully preserved, or the evaluation items lose their ability to reproduce.

Harness Fixes: The Underrated Source of Reliability

Many Agent failures are not due to insufficient model capability but to engineering problems at the harness layer—vague tool descriptions, missing error handling, improper context assembly, unsound retry logic. The NVIDIA blog places harness code fixes alongside model adjustments, indicating that in real production settings, the quality of the engineering scaffolding significantly affects Agent reliability.

By mapping failure samples to the corresponding harness modules, teams can more precisely determine whether the problem is "the model can't do it" or "the framework didn't catch it." This attribution capability is often more valuable than simply switching to a stronger model.

What Harness Means in the Agent Context

In software engineering, the term harness originally refers to a test scaffolding or test runner framework. In the Agent context, it refers to the entire set of runtime engineering code wrapping the model: tool definitions and calling protocols, strategies for assembling context and history, error capture and retry mechanisms, output parsing and format validation, loop termination conditions, and so on. The model itself only handles reasoning and generation; what actually turns reasoning into executable actions and reorganizes tool returns into the context is the harness.

Therefore the same model can perform very differently under different harnesses—if tool descriptions are vague, the model is prone to choosing the wrong tool; without error handling, a single tool timeout can crash the entire task; and improper context assembly can dilute key information in long conversations. Listing harness alongside prompts and models as a repair dimension means the focus of reliability optimization shifts from "swapping models" to "fixing engineering"—which is the key distinction between this approach and pure model evaluation.

Implementation Recommendations

For teams preparing to put Agents into production, the recommended order is: first establish a failure-evidence collection mechanism so every anomaly has retrievable context; then convert high-priority failures into evaluation cases to form a continuously runnable regression set; finally integrate evaluation results into the iteration process for prompts, tools, models, memory, and the harness. NVIDIA NeMo serves as the hub connecting "production failures" and "engineering improvements."

Agent reliability is not the result of a single tuning pass but an ongoing process of turning failures into test assets.

One-line Summary

NVIDIA proposes distilling Agent production failures into issue lists and custom evaluation sets to drive engineering improvements in reverse.

Paragraph Summary

The article presents the Agent reliability engineering approach from NVIDIA's developer blog: production failures should not be treated as one-off bugs fixed by hand, but systematically collected—failure context, inputs, tool call records, and output deviations—and turned into a prioritized issue list. On that basis, custom evaluation sets are built so that every change to prompts, tools, models, memory, skills, and harness code can be repeatably verified and regressions prevented. The article particularly emphasizes the impact of harness-layer engineering quality on Agent reliability, arguing that precisely attributing whether a problem lies in the model or the framework is often more valuable than simply switching to a stronger model. The implementation path is: first establish a failure-evidence collection mechanism, then convert high-priority failures into evaluation cases, and finally integrate them into the iteration process—with NVIDIA NeMo serving as the hub.