Verification, Evaluation and Improvement

Never accept 'done' as a claim — define done as a verifiable state of the world: tests pass, the file exists, the URL resolves, the number reconciles. When verification fails, repair with a budget: two or three attempts, each required to change approach, then stop and escalate with a report of what was tried. Unbounded self-repair is how agents dig confident holes.

The software-factory pattern: exams written before code exists, a night-shift executor that takes them, circuit breakers that stop it from digging, and a fresh reviewer that reruns everything.

LangSmith traces show you every repair attempt with its diff; a repair loop without observability is indistinguishable from a hang.

You cannot improve what you measure vaguely. Build the dataset first: 20–50 real input/expected-output pairs including the ugly edge cases. Then evaluate at two levels — node-level (is the extractor right?) and graph-level (is the shipped answer right?) — because a graph of individually-fine nodes can still compose a wrong answer, and expected-vs-actual trajectory comparison tells you which edge betrayed you.

Matei Zaharia's systems lens: evaluation infrastructure is what turns AI programs from demos into engineering; DSPy exists because metrics make optimization possible.

LangSmith runs dataset evaluations and compares graph versions side-by-side; Pydantic Evals types your cases and scores; both diff trajectories, not just outputs.

Once a node has a metric, its prompt becomes a parameter you can optimize instead of hand-tune. DSPy treats the program as a computational graph and searches instructions and demonstrations against your metric. The discipline that keeps it honest: optimize one node while the rest of the graph's metrics run as a regression suite — a better extractor that breaks the summarizer is a net loss. Then read the cost column: a 2% accuracy gain at 3× tokens is usually the wrong trade.

Omar Khattab's core argument: program, don't prompt — declare what each stage should do and let the optimizer find the words. Zaharia: measure the whole system, not the part.

DSPy optimizers (instruction search, demonstration selection) against your 4.3 metric; LangSmith regression comparison across graph versions.

LLM judges respond to things other than the content in front of them. Frontier judges systematically inflate their own model family — one 2026 benchmark measured 75–84% self-family win rates for GPT-5.2 and Gemini 3.1 Pro (Claude Opus 4.7 went the other way, under-rating its own family), with cross-judge bias on ArenaHard spanning −38% to +90%; the same outputs scored 93.3% under one judge and 39.5% under another. Verbosity bias runs alongside. Three rules absorb most of it: judge from a different family than the generator; panel across vendors for anything high-stakes (averaging across families breaks correlated errors); anything objectively checkable goes to code, not a judge. Then treat the judge as software: pin its version and log it with every score, write rubrics as “pass if the observable outcome happened,” and never reward shape — length, keywords, citation count — or you hand the agent a Goodhart target and your defense becomes an attack surface.

Hanako (@hanakoxbt)’s eval-engineering course: “A gate fed by a biased judge is worse than no gate. It launders a guess into a number and then acts on it.” And DeepMind’s ICLR 2024 result stands behind the external-grounding rule: intrinsic self-correction — a model reviewing its own work with no outside signal — does not reliably help and often hurts.

LangSmith records which judge model and version produced every score; Pydantic Evals encodes pass-if rubrics as code. This module’s read-only critics now get families: the critic that grades a node should never share a lineage with the node it grades.

A verdict that does not change the run is a report — a thermometer, not a thermostat. Mature systems map each verdict to a structural action on the run in progress: low grounding rejects the handoff, a schema failure blocks the edge, a suspected fabrication quarantines the branch, and only verified completion may end the run (an agent that stops calling tools has ended its turn, not the task). Grade the path, not just the answer — end-to-end, trajectory, and component levels, with faithfulness, tool-parameter accuracy, and task completion as the starting metrics; an identical diff that arrived after forty steps of thrashing is a different risk from one that arrived clean. Your best test cases are already in your logs: a clean run, a user-corrected run (the correction is a free label), an empty tool return, an external timeout. And the gate that finally lets agents merge without you opens on blast radius, not confidence: reversible-and-contained work opens first; reversible-but-wide needs deterministic checks plus a clean trajectory; hard-to-reverse — migrations, deletions, money — does not open, regardless of score. Inside a lane, evidence order matters: deterministic results first, trajectory second, rollback history third, and the model’s self-assessment weighted least, because it is the one input the model can influence.

Hanako (@hanakoxbt): the end state is not trust in the agent — “it is a constraint tight enough that trust stops being the question.” Run the gate in shadow first, merging nothing, and keep it closed while gate-versus-human disagreement is meaningfully above zero. Green is evidence, not proof.

LangSmith’s trajectory-level evals grade the path; promoted into runtime guardrails they become the verdict→action wiring. Module 2’s human-approval gate becomes lane-conditional: the human leaves the reversible lane first and the irreversible lane never.