Reference · Agentic Loop Engineering

The Verifier Taxonomy

A field guide to the verify step of the agentic loop — every mechanism that can give an agent a pass/fail signal, ordered from tightest & cheapest to richest & slowest. ★ marks the non-obvious verifiers worth reaching for when the obvious ones don't apply.

Gather context→ Act→ Verify ★→ Repeat
"Claude stops when the work looks done. Without a check it can run, 'looks done' is the only signal available, and you become the verification loop… Give Claude something that produces a pass or fail, and the loop closes on its own." — Anthropic, Best practices for Claude Code

The verifier spectrum

TightestCompiler · types
CheapLint · unit tests
MidFixtures · integration · logs
RichScreenshots · world-state · judge
RichestSubagent · human

Left = low latency, narrow scope, deterministic. Right = high latency, broad judgment, often non-deterministic. Prefer the leftmost verifier that can actually catch the failure you care about — then escalate only as needed.

The full menu

deterministic trustworthy, objective semi reliable but needs a runtime/oracle calibrate non-deterministic — verify the verifier ★ non-obvious / outside the box
VerifierCatchesTrustLatencyHow to wire it in Claude Code
Compiler / build exit codeSyntax, broken imports, type-incompatible codedeterministic≤ sec"Build and fix until exit 0." Stop hook on the build command.
Type checker (tsc, mypy)Contract/type violations — gold for dynamic langsdeterministicsecCLAUDE.md: "typecheck when you're done."
Linter / static analysisStyle, anti-patterns, some bug classessemisecHook: run eslint/ruff after every file edit.
Unit testsFunction-level logic — strongest cheap signaldeterministicsecTDD: commit failing tests first, then iterate to green.
★ Golden / fixture diffOutput drift vs. a known-good referencedeterministicsec"Diff output against fixture.json; fix until identical."
★ Logs-as-feedbackRuntime state the agent can't otherwise see (server up? exception?)semisecApp logs to a file; "read app.log and confirm no errors."
Integration / E2E runWhether components actually work together & the app runsdeterministicsec–minBrowser automation; "test as a human user would."
★ Screenshot / visual diffUI correctness vs. a designsemisec–min"Screenshot the result, compare to the design, list diffs, fix."
★ World-state / outcome checkWhether the world changed (DB row, file, API state) — not just the transcriptdeterministicsec–min"Query the DB and confirm the booking row exists."
★ Feature-list ground truthPremature victory on long, multi-part workdeterministicsecJSON list of ~N features w/ pass/fail; agent can't stop until all pass.
★ LLM-as-judgeOpen-ended quality / rubric adherence where no deterministic check existscalibratesecSubagent grades output against a rubric (binary pass/fail).
★ Adversarial verification subagentGaps the implementer is blind tosemisec–minFresh model sees only the diff + criteria; /code-review.
Human-in-the-loopAnything graders miss; calibration gold standardgoldmin–hrCheckpoints; review before merge/commit.

The four gates — where the verifier blocks the loop

A verifier only helps if something forces the agent to honor it. In Claude Code, escalate as the cost of a wrong "done" rises:

Gate 1 · tightest scope

In one prompt

Ask Claude to run the check and iterate in the same message: "…run the tests after implementing and fix failures."
Gate 2 · whole session

/goal condition

Set the check as a goal; a separate evaluator re-checks after every turn and Claude keeps working until it holds.
Gate 3 · deterministic

Stop hook

A script runs your check and blocks the turn from ending until it passes. (Overrides after 8 consecutive blocks.)
Gate 4 · second opinion

Verification subagent

A fresh model sees only the diff + criteria, so the agent doing the work isn't the one grading it.

Source: Claude Code best practices · Hooks · Sub-agents.

Principles that make verifiers actually work

1. Show evidence, don't assert success. Make Claude print the test output or the screenshot — never accept "done" on faith. (Best practices)

2. Commit the tests first. In TDD, commit failing tests as a checkpoint so the agent fixes the code, not the test. (Best practices)

3. Don't let the worker grade itself. For judgment calls, use a fresh-context verifier (subagent / LLM-judge). (Best practices)

4. Calibrate model-based verifiers. Measure agreement between the LLM-judge and a human before trusting it; binary beats a 1–5 scale. (Husain)

5. Error messages are feedback. Verifiers should emit specific, actionable errors — not opaque codes. (Writing tools for agents)

6. Speed is a feature. A fast check closes the loop more times per minute. Kill hanging tools. (Ronacher)