Lesson 1 · Agentic Loop Engineering

The Verify Step

The mental model in five minutes — then the part you actually came for: the verifiers that live outside the obvious test / lint / typecheck box.

⏱ ~8 min🎯 Mission: get autonomous, high-quality work from Claude Code📊 Level: comfortable user

1 · The loop, in 30 seconds

Strip away the hype and an AI agent is almost embarrassingly simple. Anthropic's own definition: an agent is "LLMs using tools based on environmental feedback in a loop." (Building Effective Agents) Simon Willison shortens it to "something that runs tools in a loop to achieve a goal." That loop has four beats:

Gather context→ Act→ Verify→ Repeat

Agentic loop engineering is the craft of designing the environment, tools, and iteration structure around the model so that loop runs well — rather than obsessing over the prompt. And the single highest-leverage beat to engineer is the one in gold.

2 · Why verify is the hard part

Three of the four beats are easy to get for free. The model gathers context and acts all day. The trouble is the third beat — and here is the sentence that should reframe how you use Claude Code:

"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

That failure mode has a name in this workspace: premature victory. The agent declares done because the transcript reads like success. Anthropic built a whole harness post around stopping long-running agents from "prematurely declaring victory." (Effective harnesses) The cure is always the same shape: give the agent ground truth — an authoritative signal from the environment about what is actually true, not what it asserts.

The reframe: with agentic loops the model gets many attempts, so the quality of your feedback mechanism now matters more than the polish of your prompt. Engineering the verifier is the work.

3 · The obvious rung — and what's above it

You already use the obvious verifiers: compiler · type checker · linter · unit tests. They're deterministic, fast, and trustworthy — always reach for the tightest one that can catch the failure you care about. But they only cover failures you can express as a pre-written assertion. Most interesting tasks can't. Here's the menu above the obvious rung — the ones you asked about:

🖼️
Screenshot / visual diff
"Implement this design. Screenshot the result, compare it to the original, list the differences, and fix them." The agent verifies UI it can't unit-test. (Best practices)
🗄️
World-state / outcome check
Did the world actually change? Verify the booking row exists in the database, the file got written, the API state flipped — not just that the chat said so. (Demystifying evals)
📐
Golden / fixture diff
Diff the program's output against a known-good reference file. Catches subtle drift no unit test was written for. (Best practices)
📜
Logs-as-feedback
Have the app log to a file, then let the agent read it back. Now "did the server start?" and "did it throw?" become observable. (Ronacher)
📋
Feature-list ground truth
For long, multi-part work: a JSON list of ~N features each marked pass/fail. The agent literally cannot reach "done" while any is false. Anthropic's antidote to premature victory. (Effective harnesses)
⚖️
LLM-as-judge
When there's no deterministic check — "is this error message clear?" — a second model grades against a rubric. Powerful but non-deterministic: calibrate it against your own judgment before trusting it, and prefer binary pass/fail. (Husain)
🕵️
Adversarial verification subagent
A fresh model that sees only the diff and the criteria and tries to refute the work — so the agent doing the work isn't the one grading it. Ships as /code-review. (Sub-agents)

The full ordered table — trust level, latency, and wiring for each — lives in your printable reference: The Verifier Taxonomy ↗

4 · Making the verifier actually bind: the four gates

A verifier is useless if nothing forces the agent to honor it. In Claude Code you escalate the gate as the cost of a wrong "done" rises:

Gate 1In one prompt
"…run the tests after implementing and fix any failures." Same message.
Gate 2/goal condition
An evaluator re-checks after every turn until the condition holds.
Gate 3Stop hook
A script blocks the turn from ending until your check passes.
Gate 4Verification subagent
A fresh model grades the diff — the worker doesn't grade itself.

Two rules make all four work: show evidence, don't assert success (make Claude print the test output or screenshot), and when using TDD, commit the failing tests first so the agent fixes the code, not the test. (Best practices)


5 · Practice — pick the right verifier

Six scenarios where the obvious verifiers fall short. For each, choose the verifier you'd reach for. You'll get immediate feedback and a short rationale.

Loading…

💬 I'm your teacher — ask me anything. Stuck on when an LLM-as-judge is trustworthy? Want help wiring a Stop hook for one of your real projects? Curious how the feature-list pattern looks in JSON? Just ask in the chat. The lessons are the scaffold; the conversation is where it sticks.

Where to go next

Suggested Lesson 2 (ask me to build it): wire a real Stop hook that blocks Claude until a check passes — turning Gate 3 from theory into a loop running on your own machine.