An agent test is only as useful as the metric and traces behind it

An agent test is only as useful as the measure behind it and the record kept of each run. Stephanie Jarmak made that case on the AI Engineer show. She builds evals (tests of AI systems) at Omni Analytics, and her talk was about how not to trust your agents.

What was said

Jarmak used to be an astronomer. At Sourcegraph she built a big set of coding tests. She said teams should approach their own evals the way a scientist would. Pick tasks that match real work. Repeat the runs, because these systems are non-deterministic, so results vary. Keep every trace, the full record of what the agent saw and did.

Her first example was an agent that ignored a tool. She worked down the chain: was the tool available, what did the agent call, what came back? Even after she improved the tool, the final outcome sometimes did not change. The agent was not using the information, and she said finding out why was her job.

Her second example was the choice of measure. In a search-tool test, Claude returned 295 files when it only needed six. She wanted an F1 score, which balances precision (how much of what came back was useful) against recall (how much of the useful material was found). If you only care about catching anything possibly relevant, she said, perfect recall may be enough. What you want, she said, depends on your business needs.

On trust, she said: "I want to automate as much as possible for the work to get done, but I also do not trust these systems, like, at all." In her own software factory, an agent noticed problems but nothing forced a stop. She said flagging and enforcing must be separate. She closed on the point that "ultimately, like, production is truth."

Why it matters

Our reading: the hard part is not running the agent but deciding what counts as success. The 295-versus-six example shows it. A recall-only score would not penalize an agent that hauls in 295 files when six will do. Only someone who chose the metric and read the trace would see the waste.

Her review example points to a second judgment call. She cited an audit of LLM-as-judge failures (an AI grading another AI's work) in a separate system. There, a 1% false alarm rate would mean 10,000 reviews if every alarm went to a human. The excerpt gives no volume, so that implies roughly a million checks. For checks that route every alarm to a human, expert capacity becomes the limit.

For a budget signer, three questions follow. Who owns the metric, and can they explain why it fits the business? Are full traces kept? When a check fails, what actually stops the work?

The other side

Jarmak spoke from her own tests and a software factory she is still experimenting with. She did not claim her method suits every team. She also allowed that recall alone can be the right target for someone whose needs differ from hers.

She did not say judging is replacing building; that framing is ours. The excerpts say nothing about how to train people for it, and they do not price repeated runs or retained traces. The review-load excerpt also stops mid-sentence, so her answer on whether organizations have enough domain experts is not in the part we have.