How I stopped winging it on evals

A couple days ago, I've realized something embarrassing.

I'd been shipping agents that ran every day. They sent briefs, pulled data, and made decisions. And the whole time, I was still judging them mostly by whether they felt right that day.

That's not an evaluation strategy. That's hoping.

I'd been telling myself I was doing evals. I had RAGAS scores lying around, a few manual spot checks, a spreadsheet I opened once a week and closed without doing much with it. It passed the "I care about quality" test in conversation, but it fell apart the moment someone asked me to explain what was drifting.

So I've finally opened inspect-ai.

What changed when I stopped winging it

inspect-ai is the framework the UK AI Safety Institute built. You define a task, give the agent tools, run it many times, and score the outcomes with custom rules. It also logs the full path the agent took, so every decision, every tool call, and every recovery attempt is right there in front of you.

The first thing that surprised me was how small the failures were.

One of my agents would occasionally drop a key data point in the morning brief. It was subtle enough that the summary still sounded coherent. When I ran it through inspect-ai with a simple scorer that checked whether the expected entities appeared, the success rate landed around 87 percent across thirty runs. Not terrible, but not good enough for something the whole team reads.

That number forced a conversation I'd been avoiding.

I've started adding explicit verification steps inside the workflow. I've stopped assuming the original output was trustworthy by default, and that mattered more than any model upgrade.

Why this felt different from the RAG scores I already had

RAGAS is excellent for retrieval. It tells you whether the context was relevant and whether the answer stayed faithful to it. That still matters a lot.

But the risk in the systems I run shows up after retrieval: the planning, the tool selection, and the moment when the agent decides to skip a verification step because the previous output looked fine.

inspect-ai lets me test that whole loop. I can write scorers that check whether the agent used the right tools in the right order, whether it handled an error gracefully, and whether the final deliverable meets a concrete definition of done. It turns evaluation from a feeling into a repeatable experiment.

I didn't need a more powerful model right away. I needed a better way to see when the current one was failing.

The part that surprised me most

Once I'd had real numbers in front of me, something shifted.

I've stopped getting defensive about the output. I can look at a failed run and say "this scorer caught something real" instead of spiraling into "maybe the prompt just needed tweaking again." That distance matters when you're the person responsible for keeping the system alive, because it turns debugging from something personal into something closer to data collection.

I still get runs where the agent does something unexpected. But now those surprises get logged, scored, and folded into the next iteration instead of disappearing into the morning rush.

What I'm still figuring out

I've only been running this properly for a few weeks. The garden isn't neat yet. Some scorers are too strict, others are too lenient, and I keep adjusting what "good enough" means for different kinds of tasks based on different kinds of taste.

The useful part is that I'm finally having the argument out loud with the system instead of inside my head.

That feels like progress worth keeping imho.

What evaluation habits have you stuck with once the system started running for other people?

Thanks for reading. Cheers.