The gap between an agent that looks productive and one that actually is comes down to one thing: whether it can verify its own work before telling you it's done.

The core problem this setup solves

Anthropic’s own Claude Code documentation names a specific, common failure mode directly: “the trust-then-verify gap” — an agent produces a plausible-looking implementation that doesn’t actually handle the edge cases, and the human only finds out after merging it. The documented fix is blunt: “always provide verification (tests, scripts, screenshots). If you can’t verify it, don’t ship it.” (Claude Code best practices). Everything below is really in service of that one idea.

Give the agent a way to check its own work

The most load-bearing piece of a practical setup isn’t a fancier prompt — it’s giving the agent something it can run and get a pass/fail answer from: a test suite, a build’s exit code, a linter, a fixture diff, a screenshot comparison. Anthropic’s docs describe three levels of enforcing this: doing it inline in a single prompt, a re-checked /goal condition, or a Stop hook that mechanically blocks a turn from ending until a script-based check passes (Claude Code caps this at 8 consecutive blocks so an agent can’t loop forever) (Claude Code best practices). The /goal condition and multi-agent “teams” framing are newer surface area in the docs — worth trying, but treat them as an if-you-want-to-go-further step rather than the foundation.

A related, well-documented pattern: have a second, fresh-context subagent review a diff against stated criteria, rather than letting the agent that wrote the code also grade it. Claude Code ships a bundled /code-review skill built for exactly this (Claude Code best practices).

Subagents: delegate the noisy parts

Subagents run in their own context window, with their own system prompt, their own tool access, and independent permissions. The practical benefit is keeping verbose exploration — grepping a large codebase, reading through a long log file — out of your main conversation’s context, so the thread you’re actually steering stays focused (Claude Code subagents docs). You define custom ones in .claude/agents/*.md with frontmatter for name, description, tools, and model — and you can deliberately pin a cheaper model to a simple, high-volume subagent task rather than running everything on your most expensive model by default (Claude Code sub-agents; best practices).

Hooks: make the important rules mechanical, not advisory

A CLAUDE.md instruction is a request — the model can forget it, misread it, or decide it doesn’t apply. A hook is not: hooks are user-defined shell commands, HTTP calls, prompts, or subagents that fire at specific lifecycle events (PreToolUse, PostToolUse, Stop, SessionStart, SubagentStart, and others) and can allow, block, or modify an action deterministically (Claude Code hooks). If there’s a rule you’ve caught yourself repeating in every session — don’t touch this directory, always run the linter after an edit, never skip test hooks — that’s a sign it belongs in a hook, not another paragraph of instructions the agent might skim past.

Isolate parallel work with worktrees

Running more than one agent session against the same working directory is how you get edits that silently stomp on each other. claude --worktree <name> creates an isolated working directory and branch per session, and subagents can request the same isolation via isolation: worktree in their frontmatter (Claude Code worktrees). Cheap insurance for anything you’re running more than one agent against at once.

The workflow shape that’s actually documented

The officially documented default is a four-phase loop: explore, plan, implement, commit — using Plan Mode to deliberately separate research and planning from the moment code actually starts changing (Claude Code best practices). It’s not a exotic technique; it’s closer to what a careful engineer already does, made explicit enough that an agent can follow it too.

Managing context and cost

MCP tool definitions are deferred by default — only tool names enter context until a tool is actually invoked, which matters once you’ve wired up more than one or two MCP servers. Prompt caching and auto-compaction are the other current, documented levers, and a hook that pre-filters noisy tool output (grepping a build log down to just the ERROR lines before it reaches the model) is a small, concrete way to keep context spend down (Claude Code costs). On cost specifically, Anthropic’s own enterprise data — self-reported, not an independent benchmark, so read it as a rough signal — puts average spend around $13 per developer per active day, with 90% of users staying under $30/day. Your mileage will vary a lot by codebase size and how much you’re running against a raw API key versus a subscription plan.

What this setup does not fix

None of this makes an agent infallible. It’s still capable of hallucinated edits, and giving it broad tool permissions “for convenience” is still the single easiest way to let a small mistake become a large one. The point of hooks, worktrees, and verification loops isn’t to remove your judgment from the process — it’s to make the failure modes visible and recoverable instead of silent.

See the AI dev workflow guide for how this fits together with picking an agent in the first place and wiring in MCP servers for context.