How to think
about testing
your agents?

There is a lot of mystique around evals. There should not be. Underneath the buzzwords, the whole thing rests on a small loop: watch real runs, name what broke, save the important cases, test before shipping, and keep watching in production.

This guide builds those ideas one at a time. Each module assumes only what came before it, and every module returns to the same refund agent.

If you have not read Zero to Agent yet, start there. It gives you the basic mental model for what is happening in this space. This guide is for what comes after: you built an agent, the prototype works most of the time, and now you need confidence before it touches real customers.

Building a prototype that works 80% of the time is easy. That is not enough for production, especially in large enterprises or sensitive healthcare, finance, and insurance workflows. If you want a simple way to test the agent you just vibe-coded, this guide is for you.

This is not a phase you do after the "real" work. It is part of building, the way debugging is part of writing software. You do not budget separately for debugging. You just debug. Evals work the same way. The minimum viable version is simple: review a small batch of real runs after meaningful changes, save the failures that matter, and keep the suite small enough that people still trust it.

A trace is the full recording of one conversation: what the customer said, what the agent did, every lookup, every tool result, and every reply. Traces are where evals come from.

Zero to Agent ended on three words: watch the traces. This is where you do it. A trace is the full recording of one run. The customer's message, every tool call, what got retrieved, and the final answer.

Do not start by writing tests. Start by reading real conversations and asking three questions:

1. What did the customer want?
2. What did the agent do?
3. Where was the first mistake?

That third question matters most. Mistakes cascade: a wrong step early forces every later step to be wrong too. The agent's final answer being wrong tells you less than the first broken step. When you are starting out, mark only the first failure in each run. Fix the cause and the later mess often clears up on its own.

Once you have read enough runs, you will notice the same problems recurring. The skill is naming them precisely. "Bad answer" tells you nothing. The actual pattern tells you what to fix.

The method is plain. Read runs, write quick notes about what broke, then group the similar notes into named patterns and count them. That is it: write notes, then group notes. It is the highest-return activity in the whole field.

Keep going until you stop learning anything new. When the same handful of mistakes keep repeating and fresh runs do not surface new ones, you have seen enough. Start with a small batch if that is all you have. As the agent matters more, read more. The goal is not to catalogue every conceivable failure. It is to find the ones that happen most.

Before you write pass/fail checks, decide what failure means. A 99% pass rate is useless if the 1% is the agent refunding the wrong customer, leaking private data, or bluffing when it should ask for help.

For an agent that stands in for a human, your goal is not a pretty average score. Your goal is trust where trust matters.

Think about a finance agent that cancels subscriptions and moves money. Impressive. Until the day it occasionally cannot answer "how much is in my account?" Then you stop trusting all of it. For agents that replace human work, a confident wrong answer is worse than an honest "I don't know." Trust beats cleverness.

Now you turn the failures that matter into tests. Start with golden cases: a small set of critical paths your agent must always handle correctly.

You do not need fancy tooling. Write them down somewhere and start with the single most common request your agent must never botch. For a refund or CX agent, the list might be:

Write each case as pass or fail. Never a 1 to 5 rating. Scores like "4 out of 5" feel informative but they are a trap. The gap between a 3 and a 4 is subjective, reviewers disagree, and everyone hides indecision in the middle. Pass or fail forces a clear call. If you want more detail, break one case into several pass or fail checks.

Here is our refund case as a real eval. Plain English first:

The most expensive mistake here is testing your prompt in isolation. Once an agent is wired up to tools, retrieval, permissions, and memory, the behaviour lives in the whole system. Not in the prompt text.

A prompt that looks perfect on its own can fall apart the moment a real tool returns a real, messy result. So good offline tests look like ordinary software tests. They take an input, run the real agent, and check what actually happened. The answer, the tool calls, and the side effects.

For our refund agent, a real test checks four things:

Two kinds of safety check, and the difference is timing.

Offline tests catch what you thought would break. Production shows you what actually confuses real customers. This is where evals stop being theory and become an operating rhythm.

Watch real runs. Find a failure. Reproduce it. Save it as an eval. Fix it. Ship. Keep watching.

How much machinery you need scales with your volume. At a few runs a day, just read them all. As traffic grows, you let the system tell you what deserves attention. Recurring stumbles become tracked issues. Big changes get tested on live traffic before rolling out to everyone. Do not reach for the heavy monitoring stack before you have read enough raw runs to know what you are looking for.

Stop here if you are new. The main loop is enough to begin. These notes are only for teams already running evals and ready for the next layer.