Learn to build evals for AI agents

A practical, no-fluff curriculum on building and running evals for AI agents. It starts with fundamentals, LLM-as-judge, trajectory scoring, and rubric design, then deep-dives into RAG evals, production monitoring, red-teaming, hard agent shapes, and the benchmark landscape. Written for engineers, PMs, and anyone shipping agents without a grading system yet.

9 modules36 lessonsUpdated July 2026

Why evals

An agent that looks right in a demo and an agent that works in production are two different products. The difference is measurement. Evals are the tests, graders, and review habits that tell you, before your users do, where your agent succeeds, where it fails, and whether your latest change made things better or worse.

This curriculum teaches you to build that system yourself. The first four modules build the core discipline: fundamentals and your first golden cases, scaling grading with LLM-as-judge, scoring the full path your agent takes rather than just its final answer, and rubrics that turn "good" into something checkable. The rest deep-dive where agents actually live: evaluating retrieval, running evals in production, testing your agent against adversaries, handling the hard shapes (multi-agent pipelines, memory, real-world writes, voice), and learning from the public benchmarks without worshipping them. Questions at any point? .

The curriculum

9 modules, 36 lessons. Open any module to read its lessons, or jump straight into one below. Short on time? Jump to the short version.

Module 1

Fundamentals

What an eval actually is, why "it looks right" doesn't scale, and how to build your first small, high-signal set of test cases.

  • 1.1What is an eval, really?Inputs, graders, and scores23 min

    Strip away the tooling and an eval is three things: an input you care about, a run of your real agent on that input, and a grader that turns the result into a score. That's it. If you can write those three down, you've built an eval.

    INPUT"Refund order #4021, it arrived damaged."
    RUNYour agent, exactly as it runs in production: tools, retrieval, and all.
    GRADERDid it call create_refund for order 4021? Did the reply confirm the refund without over-promising?

    One eval, end to end

    To make the shape concrete, follow one case all the way through: the same refund agent this course uses throughout. Everything starts with a case spec: the input plus the expectation, written down before anyone runs it. A minimal one fits in a few lines (Lesson 1.3 adds the metadata a real suite needs):

    id: refund-damaged-001
        input: "Refund order #4021, it arrived damaged."
        expect:
          - tool_called: create_refund(order_id=4021)
          - reply_mentions: "refund"

    The run step feeds that input to your agent (the production build, same prompt, same tools, same model settings) and records everything it does into a transcript. Here is what came back on one run:

    USER   Refund order #4021, it arrived damaged.
        AGENT  → tool: lookup_order(order_id=4021)
        TOOL   ← {status: "delivered", total: 86.00, refund_eligible: true}
        AGENT  → tool: create_refund(order_id=4021, reason="damaged")
        TOOL   ← {refund_id: "rf_9912", status: "processing"}
        AGENT  "Sorry your order arrived damaged. I've issued a refund
                for order #4021. You'll see $86.00 back on your card."

    The grader then walks that transcript and checks each expectation. Here the grader is plain code (parse the tool calls, match the arguments, scan the reply), and it commits to a verdict:

    {
          "case": "refund-damaged-001",
          "checks": [
            {"check": "tool_called: create_refund(order_id=4021)", "verdict": "pass"},
            {"check": "reply_mentions: refund",                    "verdict": "pass"}
          ],
          "verdict": "pass"
        }

    And the score does something next. This is the part teams forget to design. One verdict joins the verdicts of every other case into a suite pass rate. That pass rate gets compared against the last agent version, so "we changed the prompt" becomes "42 of 47 passing, down from 44." A drop blocks the change from shipping, and each failing verdict arrives with its transcript attached, so the person who reads it can see exactly which step went wrong. A score that nobody compares, gates on, or reads is decoration; decide where your scores flow before you build anything else.

    Graders, repeatability, checkability

    Graders come in three flavors, and you'll meet all of them in this course: code checks (exact, cheap, use them first), LLM-as-judge (for qualities code can't express; see Module 02), and humans (the ground truth you calibrate the other two against).

    Two properties make an eval useful rather than decorative. It must be repeatable: the same input and the same agent version should produce a comparable score tomorrow, so you can tell whether a change helped. And it must be checkable: the grader has to commit to a verdict you could defend to a colleague. "The output seemed fine" is neither.

    The mechanism behind both properties is the same: an eval is only useful as a comparison. You never care about one score in isolation; you care whether today's agent beats yesterday's. Repeatability makes the two scores commensurable; checkability makes each one mean something. Break either and the comparison silently becomes fiction: you'll change a prompt, watch a number move, and never know whether the agent changed or the measurement did.

    One caveat on "repeatable": agents are non-deterministic, so a single run is a coin flip, not a measurement. Run each case a few times and score the rate: "passes 5 of 5" and "passes 3 of 5" are different agents (Lesson 3.4 turns this into a metric).

    Eval, test, benchmark

    Three words get blurred together in every eval conversation, and it pays to keep them apart. A test, in this course a golden case (Lesson 1.3), is one input with one written expectation: the unit test of the agent world. An eval is the whole measurement apparatus: the set of cases, the runs, the graders, and the scores they produce; people also say "an eval" for a single case, so be precise when it matters. A benchmark is someone else's eval: a public, standardized task set with a fixed grader, built so different models can be compared on the same footing (Module 09). Benchmarks tell you about a base model's general ability; only your own evals tell you about your agent on your tasks. When someone says "our evals are great" ask which of the three they mean; the answer changes what the claim is worth.

    Where teams go wrong

    Three failure patterns show up in almost every first eval setup. The demo harness: the eval runs a stripped-down copy of the agent (different system prompt, mocked tools, different temperature), so the scores describe a system nobody ships. The RUN row above says "exactly as it runs in production" because every difference between the harness and production is an untested variable, and untested variables are where the surprises live. The vibes grader: a human skims outputs with no written expectation. That verdict changes with mood, can't be delegated, and can't be compared across weeks; it fails the checkability test even when the human is an expert. The scoreboard with no consequence: scores get computed and posted, but nothing gates on them and nobody reads the failing transcripts, so the numbers drift into wallpaper within a month. Each pattern breaks a different leg of the input, run, and grader triad; the fix in each case is to restore the leg, not to add more cases.

    The obvious follow-up questions have short answers. Do you need a framework? No: a for-loop over a folder of YAML files and a script that prints verdicts is a complete eval system, and it's what you should start with; buy tooling when you need history, dashboards, and teammates running the same suite. How many cases? Five gets you moving, and Lesson 1.3 tells you where to find them. When do you run it? On every change to the prompt, the model, or the tools, which is to say, constantly.

    Everything else in this course (judges, trajectories, rubrics) is just better ways to pick inputs and build graders. The shape never changes.

    KEY IDEA

    An eval is a repeatable question with a checkable answer.

  • 1.2Vibes vs. measurementWhy demos deceive19 min
  • 1.3Build your first golden casesCases you refuse to break25 min
  • 1.4Choosing what to measureCritical paths over coverage22 min

Most agents read before they act, and retrieval is where they fail silently: the reply sounds confident while the wrong documents sit underneath it. This module makes every leg of the triangle of question, context, and answer measurable.

Every module so far assumed a user trying to succeed. Some inputs are designed to make your agent fail. This module is about testing your own agent against them before someone else does.

The course so far graded one text agent talking to one user. Real deployments are messier (routers dispatching sub-agents, memory that outlives the session, hands that touch production, voices on a phone line), and every one of these shapes decomposes into evals you already know how to build.

Public benchmarks won't grade your product, but their grading designs are the best free education in eval construction. Steal the designs, read the scores critically, and finish by turning your own suite into a benchmark.

The short version

01

Start small and real. Read your agent's real failures before you write a single test. Turn each one into a golden case with a written-down expectation, and keep that case passing forever. A small set you actually read and update will teach you more than a thousand generated cases nobody looks at. Every new production failure joins the suite, so the suite grows exactly where your agent is weak.

02

Use the cheapest grader that works. Start with plain code checks, because exact matches and schema validations are free, instant, and never argue. Reach for an LLM judge only for qualities code cannot express, like tone or faithfulness. Before you trust that judge, label a sample yourself and check that it agrees with you. Humans stay the ground truth that everything else is calibrated against.

03

Grade the trajectory, not just the answer. An agent does not just reply, it acts. It calls tools, retrieves documents, and makes decisions along the way, and that path is where the bugs live. A correct answer reached by guessing will fail you later, and a friendly reply that fired the wrong tool already has. Grade the steps and the side effects, and run each case several times, because an agent that passes three runs out of five is not the same agent as one that passes five.

04

Make "good" checkable. Two reviewers who both want quality will still disagree about "good" until you decompose it. A rubric turns quality into concrete yes-or-no questions that two people answer the same way. Derive the criteria from failures you have actually seen, not from brainstorming. Prefer pass or fail over a 1 to 10 scale, because nobody can defend the difference between a 6 and a 7.

05

Evaluate retrieval on its own. Most agents read before they act, and retrieval is where they fail silently. Think of RAG as a triangle of question, context, and answer, where each leg gets its own eval. When something breaks, the metrics tell you which leg it was. A missing document needs new content, a buried chunk needs better retrieval, and an invented claim needs a prompt fix. Without the decomposition you are guessing at all three.

06

Instrument first, evaluate forever. Record a full trace of every run from day one, because traces are the raw material for everything else. Offline suites replay them, online judges score samples of live traffic, and review queues route the suspicious ones to a human. Evals then run on every code change, so a regression blocks the merge instead of reaching a customer. Production is not where evals stop, it is where they get their data.

07

Attack your own agent. Everything else assumes a user trying to succeed, but some inputs are designed to make your agent fail. Its attack surface is everything it reads, including retrieved documents and tool results that an attacker can write. Build adversarial cases the same way you build golden ones, just with hostile intent. And always measure both directions, because an agent that refuses attackers while refusing real customers has only moved the failure.

08

Hard shapes decompose into machinery you already own. Routers are classifiers, so grade the routing decision like any tool choice. Memory reads and writes are tool calls, so grade them as trajectory steps. Agents that write to production get a shadow mode first, where intended actions are logged and graded but never executed. Voice agents get layered metrics, because no downstream eval can fix a word the agent misheard.

09

Steal benchmark designs, not scores. Public leaderboards will never grade your product, but the people who built them solved grading at scale, and their designs are published. The serious ones engineer tasks whose success is verifiable by code, like a passing test suite or a correct final state. Use leaderboards to shortlist models, then let your own suite make the decision. The end state is a benchmark for your own product that anyone on the team can run and trust.

LIVE CHAT

Ask the tutor

Stuck on a concept, or wondering how to build an eval for your own agent? Ask away. Answers are grounded in this curriculum and cite the lessons they come from.

Hi, I'm the buildevals tutor. Ask me anything about building and running agent evals: fundamentals, LLM-as-judge, trajectories, rubrics, RAG, production, red-teaming, or benchmarks.

Frequently asked questions

What is buildevals?

buildevals is a free, open curriculum that teaches you how to build and run evals for AI agents. It spans 9 modules and 36 lessons, from fundamentals and golden cases through LLM-as-judge, trajectory scoring, rubrics, RAG evaluation, production monitoring, red-teaming, hard agent shapes, and public benchmarks.

Who is it for?

Basically anyone interested in evals. Whether you are shipping AI agents and want a grading system instead of vibe checks, or just curious how evals work, the lessons explain each idea from the ground up, so a PM can follow them as easily as an engineer.

Is it really free?

Yes. Every lesson is free to read. There is no account to create, no signup, and no paywall.

How does the Ask the tutor chat work?

The tutor answers only from this curriculum. Each question is matched against the lessons, and if nothing relevant is found it declines rather than guessing. Answers cite the specific lesson they come from, so you can read the full version, and it will not answer questions unrelated to building evals.

Can I share or reuse the material?

Yes. The curriculum is free and open, so you are welcome to share links, quote it, and use it with your team. A link back to buildevals.com is appreciated.

Who made it?

buildevals was built by Tamas Szuromi. You can find him on X and LinkedIn.

How current is it?

The curriculum was last updated in July 2026. It is maintained as the field changes, and new failure modes and techniques are folded into the relevant lessons rather than bolted on as a changelog.