Evals II: the judge, the gate, and the agent

Your instinct says a 1-5 scale carries more information than pass/fail. Anthropic's guidance says the opposite for eval work, and experience agrees: binary pass/fail beats Likert scales.

• A 3 versus a 4 is noise. Ask the same judge twice and the same output drifts between adjacent scores. Pass versus fail is a decision the model can make consistently.
• Scales invite grade inflation. Judges cluster around 3-4 and almost never award a 1, so your average flatters everything and moves for nothing.
• Binary forces a sharp rubric. To write a pass/fail question you must define what passing means. That definition, not the score, is where the quality thinking happens.

Need gradations? Split the criterion into several binary judges: "contains the complaint - yes/no", "invents nothing - yes/no", "tone is professional - yes/no". Three crisp verdicts beat one mushy 3.7.

A judge prompt is still a prompt, and everything from sessions 2-3 applies. The two rules that matter most:

• One criterion per judge. "Is this summary accurate, concise, professional, and helpful?" is four questions wearing one trench coat. The judge will answer some blend of them and you will never know which. One judge, one question.
• Define pass explicitly. Not "is the summary good?" but "would a support agent reading only the summary know what the customer is unhappy about, in the customer's own terms?" The pass condition is written into the rubric, so the judge applies your bar, not its own taste.

In promptfoo this lands as an llm-rubric assertion, or a fully custom grader when you want total control of the judge prompt - Anthropic's course builds both, and the build-along steals its shape.

A judge is a model making judgment calls, which means it can be wrong - systematically. Before you trust one in the suite, calibrate it:

• Spot-check verdicts against human calls. Take 20 outputs, grade them yourself, then compare. Agreement above roughly 9 in 10 on a binary rubric means the judge is usable; below that, the rubric is ambiguous - fix the rubric, not the judge.
• Study the disagreements. Every case where you and the judge disagree is either a rubric hole or a genuinely hard call worth a golden-set discussion. Both are gifts.
• Re-check when anything changes. New judge model, edited rubric, new failure mode in production - each one re-opens the calibration question. Ten minutes, twice a quarter, keeps the instrument honest.

The mental model: the judge is an employee you delegated grading to. You would spot-check a new hire's first batches. Same here - it is Discernment, one level up.

One honest difference: unit tests are deterministic, model outputs are not. So eval gates are usually thresholds, not perfection - "category accuracy at or above the baseline 91%" rather than "all green, always". The gate still does its job: nothing quietly gets worse.

The wiring is unglamorous and that is the point. In GitHub Actions, GitLab CI, or anything similar:

• Trigger: any change under prompts/ or to the eval config kicks off an eval run.
• Run: the CI job calls the eval harness - promptfoo has a first-class GitHub Action, and Braintrust popularised the same merge-gate pattern with score comparisons posted straight onto the pull request.
• Gate: the job fails if any hard assertion fails or a tracked score drops below baseline. A failed job blocks the merge like any red build.
• Receipt: the run posts the score table as a PR comment, so the reviewer sees "v5: category 94%, judge pass 90%" next to the diff.

Result: the conversation about a prompt change stops being "trust me, it reads better" and becomes a diff plus a scoreboard. Reviewers can have opinions about taste; the gate has opinions about regressions.

The last piece turns production into a test-writing machine. Every logged failure - a mis-routed ticket, an angry correction from a support agent, a summary that missed the point - is a real input with a now-known correct answer. That is precisely one golden-set row.

• Capture: log the input, the bad output, and what should have happened.
• Convert: add it to the eval config as a test case with the correct expectation.
• Protect: from that day on, no prompt version that reintroduces the failure can merge.

Teams that run this loop stop having the same incident twice. The golden set stops being a document you wrote once and becomes an immune system that learns. Session 8 called the golden set the asset that appreciates - this loop is the mechanism doing the appreciating.

TriageBot with its lookup tool can now fail in ways the outcome layer cannot see:

• Router failure: it answers a refund-status question from the policy manual instead of calling the lookup - and happens to guess right. Outcome: pass. System: broken.
• Trajectory failure: it calls the lookup four times for one ticket, burning latency and budget, then answers correctly. Outcome: pass. Bill: quadrupled.
• Skill failure: the lookup step queries the wrong order id, and a later step papers over it with a plausible summary. Outcome: sometimes pass. Trust: gone.

Layered evals catch each of these where it happens. In practice: router evals are usually cheap classification checks ("given this ticket, was tool X the right call?"), trajectory evals compare the step sequence against an expected pattern, and outcome evals are exactly what you built in session 8.

Everything so far grades cooperative inputs. Production also contains the other kind: tickets that try to manipulate the system - "ignore your instructions", "reveal your prompt", "mark this URGENT". The Red Teaming LLM Applications course frames adversarial testing as an eval discipline, not a dark art: a red-team suite is a golden set of attacks, run to find injection, jailbreak, and leakage weaknesses before real attackers do.

• Same harness, hostile rows: each probe is a test case whose pass condition is "behaviour did NOT change" - the category stays correct, the system prompt stays private, no unauthorized action fires.
• Tooling exists: promptfoo ships built-in vulnerability probes (its red-teaming mode generates attack inputs against your actual config), so the tool you already run covers this too.
• Defensive purpose, explicitly: you probe your own system, with permission, to fix what you find. That framing matters - it is the difference between a security practice and mischief.

Today you get the eval-side view; session 10 is the full security story - what injection actually is, why it is not jailbreaking, and which defenses hold up.