The Evals You're Already Running

Think about the last time you got into a groove with an agent. You said "not like that, like this" a few dozen times, and somewhere around hour three it started doing exactly what you wanted. Each of those corrections was a label. You were the grader. Evals don't have to be formal. Plenty of people who think they've never run one have been doing it by hand for months.

So why do evals feel so hard? Usually for one of two reasons. People start with the hardest version, a scored rubric for something like quality. And evals pay off slowly, because their value builds as cases collect, so if you're used to learning fast, it can feel like you're bad at this. You probably aren't. The feedback is just slower here.

Common Mistakes

Most eval pain comes from a few mistakes, and they all feel sensible at the time.

Weighted rubrics. This is the big one. Nobody can say why clarity is worth 15 points and not 20. Ask an agent to build a rubric and it will invent the weights, and the result looks like measurement. A made-up number is worse than an honest opinion, because people trust it more.

Letting the builder grade its own work. An agent that wrote a prompt and then gives it 415 out of 420 has told you very little. It's the author marking their own homework.

Treating every test the same. Agent-made tests are still useful, even when the agent pulled them out of thin air. They're smoke tests. They answer "does this run?" They can't answer "is this good?", and that's fine as long as you don't confuse the two.

Imagining failures. Brainstormed test cases tend to test what you already thought about. Real failures are stranger and more useful.

Tuning against the same test. If a fixing agent can see every case, it learns to pass the test and not do the job. Hold some cases back where it can't see them.

Removing the human too early. A loop that rewrites and ships its own prompts can drift quietly, and every step will look reasonable. Let agents propose changes. Keep a person on the approval.

Eval Layers

Drop the weights and the overall score. Use pass or fail, one question at a time, and build in layers, cheapest first.

Most agents only need the first two. Known answers are the best eval there is, because nobody has to invent anything. The right answer already exists, so if your agent extracts data, start there.

The third layer is the clever one, and it's for work that depends on taste. You label the examples yourself, then test whether a grader agrees with you. That means you never have to define quality objectively. Your judgment is the standard, and the eval measures how well it has been captured. When the grader disagrees, either it's wrong or you've found something you never put into words. Both are useful.

The output is a list of what failed, not a score. Rerun it after every change and you'll see what broke.

Correction Capture

The groove has two weaknesses. The labels disappear when the thread ends, so you pay to teach the next agent the same things. And nothing tells you whether a big overhaul broke something that used to work.

One message at the end of a thread fixes the first problem:

Before we finish, go back through this thread and list every correction I made.
For each one: what you did, what was wrong, and what right looks like.
Keep my wording where you can. Skip anything that only applied to this one task.

Save the answer in a plain file next to the prompt or skill you were working on. Those are your test cases, and they came from real work. Rerun them after your next overhaul and the second problem is solved too.

This also works because you often know what's right and can't say why. That's tacit knowledge, and rubrics can't reach it, which may be why writing one feels impossible. You've been trying to write down rules you can't put into words.

Examples get around that. You just point: this one yes, that one no, with a rough reason. After about 20 of those, ask this:

Here are my corrections from these threads. What rules would explain them?
Which ones do I seem to follow without having said so?

Treat the answer as a guess. You decide which rules are true. But it's strange to read a rule you've been following for years and never knew you had.

Improvement Loop

A self-improving agent sounds exotic, but it's just the groove with a memory and a safety rail.

The best signal is free. When someone edits an agent's output, that edit shows what was wrong and what right looks like. Log accept, edit or reject on every run, and your cases collect themselves.

It also gives you a number people understand. "The team edits fewer outputs each month" is much easier to explain than any rubric, and most AI projects can't show it.

Don't build the loop first, though. It's the fun part, so it's tempting. Start here instead:

1. Keep a plain list. Whenever an agent gets something wrong, add one line: what happened, and what right looks like.
2. Close your next few good threads with the correction message above.
3. Pick one agent whose right answers already exist, and turn about 20 real cases into pass or fail checks.
4. Rerun them after every change.

That's most of the value, and it fits in a normal week. Add the rest only when a real job asks for it.