Evaluating agents before you put them in front of users

Start from rejected work, not happy paths

The most valuable evaluation data in any organisation is the pile of drafts a reviewer previously rejected, along with the reason. Those cases encode the standards that nobody wrote down. We collect them first, before writing a single prompt.

A useful starting set is small, with 60 to 150 cases, but it must span the awkward inputs: scanned pages, contradictory sources, missing fields, unusual units and the edge cases the team argues about.

Four metrics that survive contact with reality

We report these per category, never as a single global average, because averages hide the failures that matter.

• Groundedness: does every claim trace to a retrievable source span?
• Task completion: did the run reach a decision a reviewer accepted without edits?
• Escalation precision: when the agent asked for help, was that the right call?
• Cost and latency per accepted output, not per run

Regression gates in the delivery pipeline

Evaluation only changes behaviour when it blocks a deploy. Each prompt, model or retrieval change runs against the frozen set, and a drop beyond an agreed threshold in any category fails the build. Model upgrades are treated as breaking changes until the run proves otherwise.

We keep a small held-out slice out of the loop entirely so that improvements are not just the result of fitting the evaluation set.

Monitoring is the second half of evaluation

After launch, the same metrics run against sampled production traffic. Reviewer edits and rejections flow straight back into the evaluation set, which means the system gets a sharper test every month rather than a stale one.