How to know your agent got worse

A minimal eval harness: twenty cases, a deterministic check where possible, and a rule for when to re-run it.

Level 310 minRunning agents in production

The most common failure in agent work is not a bug. It is a model, prompt, or tool change that made things subtly worse while everyone agreed it felt better.

Why vibes fail

Human review of agent output has two problems: it is not repeatable, and it is not free. After the twentieth sample you start skimming, and the sample you skimmed is the one that would have caught the regression.

An eval does not need to be sophisticated. It needs to be cheap enough to run on every change and specific enough to fail when something breaks.

A harness you can build today

**Twenty cases, from real failures.** Not invented ones. Every time a user reports something wrong, add it. The set becomes a history of what actually goes wrong, which is more valuable than a benchmark.

**A deterministic check where possible.** Exact match, contains-a-string, JSON schema validation, exit code zero. Anything you can assert without a model.

**A rubric where you cannot.** For open-ended output, define three criteria and score 0/1/2 per case. Use a model as the judge only after you have calibrated it against ten human-scored examples.

**A pass threshold and a baseline.** "18 of 20" is a decision rule. Without a baseline number, the number is decoration.

When to run it

On every prompt change, on every tool addition, and on every model upgrade. That last one is the important one: model upgrades are the most common cause of silent regressions, because they change behavior nobody asked them to change.

Put it in CI if you can. A failing eval should block a deploy exactly like a failing test — and if it can't block, it isn't a test.

What not to evaluate

Tone, thoroughness, and "quality" in the abstract. They are real but they are not stable enough to gate a release, and measuring them badly is worse than not measuring. Spot-check those on a schedule instead.

The uncomfortable part

An eval set you never update drifts away from what your users actually do. Twenty cases from six months ago measure the product you had then. Treat additions as part of the maintenance, not a one-off project.

Next: guardrails.

Prompts to practice with