Observability shows what an agent did; evaluation tells you whether it was any good — and, crucially, whether your last change made it better or worse. Because agents are non-deterministic and there is rarely a single correct answer, you cannot rely on the pass/fail unit tests of ordinary software. Evaluation is the empirical discipline that replaces "it seems to work" with evidence, and it is what lets you improve a system you cannot fully predict.

19.1 Offline and online evaluation

Two complementary regimes. Offline evaluation runs the agent against a curated dataset of inputs with known-good expectations, before deployment — your regression suite and the gate on every change to a prompt, model, or tool. Online evaluation measures quality on real production traffic — sampling live runs (from the traces of Ch. 18), scoring them, and watching for drift the offline set never anticipated. Offline catches regressions; online catches reality.

19.2 What to measure, and how to score

Agents need evaluation at multiple levels: the final output (was the answer correct, grounded, safe?), each step (did it pick the right tool with the right arguments?), and the trajectory (was the path efficient, or did it loop and waste budget?). Scoring methods range from cheap and exact to rich and expensive: deterministic checks (does the JSON validate? does the code pass tests? does the answer match a reference?); statistical similarity to references; human review (the gold standard, the bottleneck); and LLM-as-judge, where a model scores outputs against a rubric — scalable and surprisingly effective, but itself fallible and in need of calibration against human labels.

19.3 Eval-driven development

The mature practice inverts the usual order: you build and grow an evaluation set first, and treat it the way software teams treat their test suite. No prompt edit, model swap, or tool change ships without running the evals and confirming it didn't regress. Every production failure becomes a new eval case so the same mistake can never silently return. This is the empirical backbone that makes prompt optimization (Ch. 7's DSPy), model routing (Ch. 6's gateway experiments), and any other change safe to make — because you can prove its effect.

19.4 Adversarial evaluation and red-teaming

The evaluation so far measures whether the agent does its job well. Security demands the mirror image: whether an adversary can make it do something else. Chapter 16 names the threats — indirect prompt injection, the lethal trifecta, tool misuse, data exfiltration; red-teaming is how you keep those defenses closed over time. Maintain an adversarial suite alongside the quality evals: injection payloads hidden in retrieved and tool-returned content (Ch. 11, 16), jailbreak and policy-bypass attempts, and exfiltration probes — run on every change, exactly as §19.3 runs the regression set. The discipline mirrors eval-driven development: every discovered exploit becomes a permanent test case, so the same attack can never silently reopen, and the attack-success rate becomes a security indicator you drive toward zero (Ch. 29).

Mature programs make this continuous: an attacker model generates fresh adversarial inputs against the agent automatically, surfacing new weaknesses faster than a manual red team can. The defenses (Ch. 16) and the offense (here) are two halves of one control — guardrails state the policy; adversarial evals prove it holds.