NVIDIA shows how to turn agent failures into regression tests

Start with the failure the user experienced

NVIDIA published a November 4 walkthrough for improving agents using recorded failures rather than generic model rankings. NeMo Compass examines traces, NeMo Eval Author helps create evaluations, and developers change the surrounding agent instructions or code before testing again.

The tutorial uses a fictional workplace assistant that sends a message when asked only to draft one. It compares behavior on development tasks and held-out tasks after a harness change. This is a worked example, not proof that the same modification will make an arbitrary production assistant reliable. Source: Use NVIDIA NeMo to Turn Agent Failures into Tests and Harness Fixes

Why changing the model may miss the problem

Our analysis: an agent failure can originate in several places. The model may misunderstand a request, but a tool description may also be ambiguous, required context may be missing, or application code may permit an action that should have been blocked. Replacing the model does not necessarily fix those surrounding conditions.

A trace is useful when it shows the decision point. For example, it should be possible to distinguish an assistant that chose the wrong operation from one that chose the right operation but supplied invalid arguments. Those failures suggest different repairs.

The goal is a testable explanation of what went wrong. A statement such as 'the agent needs better reasoning' is too broad to guide a controlled change. A statement identifying an unauthorized operation after a draft-only request creates a much clearer evaluation target.

Turn requirements into observable checks

Our recommendation is to describe success in terms of behavior that can be inspected. If a task authorizes a draft, a test can check that the expected draft exists and that no delivery operation occurred. Checking only the final text would miss an unwanted side effect.

Tests should also distinguish inability from restraint. An assistant that never calls any tool may avoid unauthorized actions while failing every useful task. A balanced suite should include cases where execution is explicitly authorized, so a safety fix does not silently disable the workflow.

Similar reasoning applies to retrieval and data access. A correct answer should be supported by the permitted evidence. A lucky answer from an unrelated source is not a reliable completion, even if a superficial grader marks the wording as correct.

Keep some cases out of the repair loop

NVIDIA’s separation of development and held-out tasks is important. If the same examples are used to discover the failure, write the fix and declare success, a system can improve on those examples without addressing the underlying behavior.

Our analysis is that held-out evaluation needs operational protection. The agent proposing a repair should not receive the hidden cases as convenient debugging material. Once those cases are repeatedly inspected and optimized against, they no longer provide the same independent check.

Varying phrasing alone may be insufficient. A stronger suite changes the surrounding circumstances: missing information, conflicting instructions, a tool timeout or a task that spans more than one resource. These variations test whether the repaired behavior survives realistic changes in context.

Treat the harness as versioned software

A prompt change can alter production behavior just as a code change can. Teams should retain the previous version, record the reason for the edit and preserve the evaluation results that justified it. That makes rollback possible when a new failure appears.

Sensitive information in traces also needs deliberate handling. Useful debugging evidence does not require unrestricted access to every customer record. A team can define what to retain, what to redact and who can inspect it before collecting a large trace corpus.

The practical value of NVIDIA’s walkthrough is the discipline of closing the loop: observe a concrete failure, build a meaningful test, change one relevant part and check for regressions. The objective is not an agent that never produces an error message. It is an agent whose failures become understandable and whose improvements survive new tasks.