Your Benchmark Passed. What Didn't It Test?

The dashboard is green, and the release decision moves closer.

The agent passed the checks in front of it. That matters. But as the score becomes a release argument, I want to know what the checks actually saw.

A Pass Has a Shape

A shared benchmark compares systems on defined tasks. A product-specific eval checks requirements for a particular workflow. Either way, a passing score has a narrow reading: in these runs, the recorded behavior met the checks that were applied.

That can help catch regressions and make a model, prompt, retrieval, or tool change less blind. The trouble starts when that result quietly becomes a larger claim:

The agent works.

“The agent works” might require evidence that it handles missing information, conflicting instructions, stale context, tool failure, state changes, permissions, escalation paths, or attempts to push past a boundary. The benchmark may cover some of that. It may cover none of it.

A green result cannot speak for behavior it never observed. Nor does a grader's pass settle whether its checks represent the requirement the product actually has.

The Boundary Is Often Where the Risk Lives

Benchmarks are easiest to read when the expected answer is clean.

Did the agent return the right field? Choose the right option? Summarize the document? Call the expected tool? Refuse the prohibited request?

Those checks can be valuable. They are also only one part of agent behavior.

Many consequential misses do not appear as a bad final answer. They sit at a boundary:

• The agent has an answer, but not enough authority to act.
• The agent has context, but the context is stale.
• The agent retrieves a fact, but the source no longer applies.
• The agent completes the task, but skips the condition that made the task allowed.
• The agent follows the instruction, but violates the workflow rule that should have constrained it.

A benchmark that checks only the final response may miss those boundaries. A benchmark that checks only a happy path may miss what happens when the path is blocked. A benchmark that checks one turn may miss what the agent carries into the next one.

The pass becomes useful when the team can name the measured behavior in plain language:

• The agent selected the right tool when the required field was present.
• The agent refused when the required permission was absent.
• The agent preserved the requested format across the covered examples.
• The agent answered within the expected source boundary for this document set.

Those claims only hold if the checks saw the relevant tool calls, permissions, format, or sources. A grader that sees only the final answer cannot establish how the agent got there. Even on the covered cases, a passing score depends on the grader applying the intended rule correctly.

Release Decisions Need Evidence for the Decision

Before a benchmark result becomes a release argument, the team needs to name the decision it supports.

Is this evidence for a demo? A limited internal rollout? A workflow where the agent drafts but does not act? A workflow where the agent takes an external action? A workflow where it handles permissions, memory, or user-specific state?

Each decision needs different evidence. A benchmark that is enough for one may be too thin for another.

The release question is not simply, “Did the benchmark pass?”

It is, “Does this evidence cover the behavior that matters for this release?”

If the agent only recommends, the boundary may be answer quality and source use. If the agent acts, the boundary includes permission and reversibility. If it uses memory, the boundary includes what gets stored, what gets retrieved, and whether that context is still valid. If it routes work to a human, the boundary includes what the person can see and decide.

A benchmark pass belongs inside that argument. It should not replace it.

The Nugalaxy Evaluation Cases show how apparently acceptable agent behavior can still miss a requirement that matters.

Read more about harness engineering here.

The dashboard can be green while the most important boundary remains untested.

That does not make the benchmark wrong.

It means the benchmark has finished speaking.