Agent evals: how I stop shipping silent regressions
Golden sets, trajectory checks and cheap LLM-as-judge runs wired into CI, so an agent breaking a tool call shows up in a diff and not in a support ticket.
Agents fail quietly
A model that breaks usually throws. An agent that breaks returns something plausible. It picks the wrong tool, passes a slightly wrong argument, or stops one step short and writes a confident summary about work it never did.
By the time a human notices, the trace is gone and the cause is a prompt change someone merged three weeks ago.
Three layers of tests
Unit level. Format the tools, parse the arguments, render the prompt. Pure code, fast, runs on every commit. This catches the embarrassing failures.
Golden set. Real requests with expected behaviour and expected output shape. Thirty to a few hundred cases. Run on every prompt or model change, and treat a failure as a blocker, not a notification.
Trajectory checks. For anything multi-step, grade the path and not just the answer: was the right tool called, with the right arguments, in a sensible order, and did it stop when it should have?
LLM-as-judge, used carefully
A judge model is useful for open-ended quality when you calibrate it. The trick is to give it a rubric with named failure modes, ask for a short reason before a score, and spot-check its judgements against your own on a sample every week.
If the judge and I disagree more than about one time in ten, the judge is the bug, not the agent.
Wire it into the boring machinery
Same runner as the rest of the test suite, same CI, same reporting. Failures print the trace, the exact prompt version, and the diff that changed it. If evals live in a notebook, they are already dead.
The habit that matters
Every production bug becomes a test case before it becomes a fix. That order is what turns a pile of prompt tweaks into a system you can reason about, and it is the only reason I trust my own agents on a Friday.
