Phase 8 · Months 7 to 9

Build evals that catch regressions

Evals test behaviour

You still need unit tests, but they cannot tell you whether a system that gives different answers each time does its job. An eval checks whether the whole system succeeds on representative tasks. The eval dataset becomes one of the most valuable parts of the platform, because it records what the organisation means by good behaviour. On a team where agents write most of the code, evals are also how you trust an agent's change to an agent system.

Combine three kinds of checks

Use fixed assertions wherever you can: valid schema, required citations, correct tool arguments, forbidden actions, and exact retrieval targets. Add human review for quality that is hard to define. Use a model as a judge when you need scale, but calibrate the judge against human labels and never treat it as the ground truth.

Choose metrics and thresholds

Use precision, recall, false positives, and false negatives for behaviour that works like classification. For tool use, measure whether the agent picked the right tool and passed the right arguments. For retrieval, use recall at k and ranking measures. For the whole agent, write a success rubric for each task. Track cost and latency next to quality.

Turn failures into test cases

Consider every meaningful production failure for the eval set. Reproduce the failure, reduce it to the smallest case, label the expected behaviour, and fix it without making the rest of the suite worse. Run a representative subset on every pull request and the full suite before each deployment.

Build two benchmarks

Build an answer-quality benchmark for your product from real queries and complaints, and make every prompt or model change pass it. Build a PR-review benchmark with clean pull requests, obvious bugs, subtle bugs, architecture violations, and traps that tempt the reviewer into false positives. Label the expected findings. Compare prompt, model, and workflow versions, and keep records that make runs comparable.

You are done when

You can reject a prompt or model change because measured quality dropped. You can say which group of cases failed, and whether retrieval, reasoning, tool use, or the merge step caused the drop.

Exit checklist