verifier-loop

The verification loop — the closing layer of six-layer-agent-architecture. “Claude said it’s done” is not, by itself, useful information. Without a verifier you can’t tell whether the work happened correctly, can’t roll back when it didn’t, and can’t audit later (2026-04-27-claude-code-architecture-governance-engineering).

Layered verifiers

Bind acceptance criteria up front

Every Prompt, Skill, and claude-md should declare what counts as done before Claude starts working — not after. Example block:

## Verification

For backend changes:
- Run `make test` and `make lint`
- For API changes, update contract tests under `tests/contracts/`

For UI changes:
- Capture before/after screenshots if visual

Definition of done:
- All tests pass
- Lint passes
- No TODO left behind unless explicitly tracked

The diagnostic question

If you can’t articulate what “done” means for a task, it’s probably not a good fit for autonomous Claude execution. — tw93 (2026-04-27-claude-code-architecture-governance-engineering)

A useful triage: when an agent task feels under-defined, the missing piece is usually the verifier — not the prompt or the toolset.

Distinct from Hooks

Hooks enforce (block, fail-loud); verifiers report. Hooks are how a verifier becomes hard. A cargo check Hook on every Edit is a verifier wired in deterministically rather than left to the model to remember.

Where this sits in the larger Harness

2026-04-27-agent-principles-architecture-engineering reframes the verifier-loop as one slice of harness — specifically, the acceptance baseline + feedback signal components. Harness is the cross-system frame; verifier-loop is its claude-code-shaped instantiation. Two practical takeaways from the broader frame:

• Read transcript and outcome. “Claude said done” → transcript. “DB row exists / tests pass / file changed” → outcome. Pure-transcript graders miss legitimate creativity (and false-success). Pure-outcome graders miss intermediate steps that went wrong. See agent-evaluation.
• Fix the verifier before the Agent. When verification scores drop, the first instinct should be “is the verifier itself broken, drifted, or under-resourced?” — not “the model regressed.” This is the same rule agent-evaluation applies to eval suites.

OpenAI Codex: agent-driven verification at runtime

2026-04-27-harness-engineering-codex-agent-first sharpens the feedback signal component with two concrete patterns now used at OpenAI codex:

• Chrome DevTools Protocol bridge. Codex drives the application UI directly — taking DOM snapshots before / after a target user-interface path, observing runtime events through DevTools, applying fixes, restarting, and re-running until the app behaves correctly. The agent is no longer reading a screenshot a human captured; it’s running the verifier loop against the live application.
• Linter error messages with embedded fix instructions. Custom Codex-written linters enforce architectural-invariants and “taste” rules. The error messages are written for the next Codex run — they include the fix the agent should apply. The verifier produces actionable feedback, not pass/fail.

Both reduce the loop’s reliance on human attention: when the verifier itself can be queried, run, and acted on by the agent, the human review slot becomes opt-in. See ralph-wiggum-loop for how multiple agent reviewers + verifiers compose into a self-driving PR cycle.

Anthropic’s productized verifiers: verification skills and /goal

2026-07-12-loop-engineering-getting-started (anthropic Claude Code team) ships the same instincts as first-party product surface:

• Verification skills. Encode your manual checks as a SKILL.md so the agent verifies its own work end-to-end, with tools that let it see, measure, or interact with the result — “the more quantitative the checks are, the easier it is for Claude to self-verify.” The post’s verify-frontend-change example requires browser interaction, before/after screenshots, a clean console, and a DevTools performance trace before a UI change may be declared done — the same acceptance-criteria-up-front rule as the block above, packaged as a Skill.
• /goal as an externalized terminator. An evaluator model checks the user-defined success criterion each time the agent tries to stop, and sends it back until goal-met or turn-cap. This removes “good enough” judgment from the working agent entirely; the post stresses deterministic criteria (tests passed, score thresholds) — the loop-engineering page carries the full taxonomy.