Human in the Loop: Where to Put Approval Gates for Claude Agents

Sort checks into objective and judgment, then build approval gates with plan mode, ask rules, read only subagents and goals

There are two ways to get agents wrong. You can approve every single step, which turns a fast tool into a slow intern. Or you can approve nothing, which works right up until the day it really does not. The useful middle is a small number of specific checkpoints, placed exactly where your judgment changes the outcome. This guide shows how to find those points and build them into Claude and Claude Code.

Two kinds of checks

Before placing any checkpoint, sort every check in your workflow into one of two buckets.

Objective checks have a right answer that something other than you can confirm. Does the code compile, do the tests pass, does the link resolve, does the number match the source document. These should not need you at all. They belong in tests, scripts and hooks.

Judgment calls have no right answer, only a better one. Is this the right angle for this client. Does this sound like us. Is this tradeoff worth it. These are the checks that need a person, and they are usually the reason the work is worth doing in the first place.

Most teams do the opposite. They spend their review time checking links and formatting, and skim the part that needed a human. Sort first, and your attention goes where it matters.

Where a human always stays

Some gates never come out, however good the agent gets:

  • Anything irreversible: deleting data, force pushing, dropping a table
  • Anything that leaves your hands: sending an email, posting, publishing, messaging a customer
  • Money, contracts, legal and medical decisions
  • Production deploys and security settings

A long clean streak is not evidence that an agent is safe here. It only means nothing bad has happened yet.

Map your workflow in one prompt

Open the Claude project or conversation where you already do the work, so it has your real steps, and paste this:

Look at the workflow we use in this project. Rewrite it as a sequence of steps and,
for each step, tell me:
1. Who does it: me, Claude, or a script.
2. What can go wrong at that step.
3. The check that catches it, labeled OBJECTIVE (a test or script could confirm it)
   or JUDGMENT (only I can decide).
4. The evidence I need to see to approve it, in one line.
5. What happens when the check fails.
Mark every step that is irreversible or sends something outside as a permanent
human gate. Then list the three OBJECTIVE checks I should automate first.
Use my actual steps, not a generic template.

If the answer comes back as a blank framework, reply "use the real steps above" and run it again. What you want is your workflow with three or four gates, each one specific.

Build the gates in Claude Code

A gate before any work starts: plan mode

Press Shift+Tab until the status bar shows plan mode, or start a single prompt with /plan. Claude reads, explores and writes a plan, but cannot edit your source until you approve it. Press Ctrl+G to open the plan in your editor and change it directly. This is the cheapest judgment gate there is. Five minutes on the plan saves an hour of reverting.

A gate on dangerous actions: ask rules

Put the irreversible and outward actions behind ask rules in .claude/settings.json. They prompt you every time, even in auto mode.

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(rm *)",
      "mcp__*__send*"
    ]
  }
}

Agents that report back instead of acting

A subagent is Claude with one job, its own instructions and its own tool list. Give it tools that can only read and research, and it can only bring you results, never act on them. Save this as .claude/agents/researcher.md:

---
name: researcher
description: Researches a question on the web and returns a sourced summary. Use for any fact finding.
tools: WebSearch, WebFetch, Read
---

You research one question at a time. Return at most five findings.
Every finding needs a working source URL you actually opened.
If you cannot find a source, say so. Never guess a link.
You do not write files or send anything. You report back.

Then ask: "Use the researcher subagent to find out how our three main competitors price their team plans." It works on its own, and you get a sourced summary to judge. The subagents docs cover every field.

Objective gates that run without you

For checks with a clear pass or fail, let Claude grade itself against something real. The simplest version is /goal:

/goal npm test exits 0 and npm run lint shows no errors, without editing any test file

A separate fast model checks the condition after every turn and keeps Claude working until it holds. For checks you want in every session, a Stop hook does the same job from your settings file. Either way, you stop reading test output and start reading the result.

How a checkpoint graduates

Every time you correct the same thing twice, move the fix one step up this ladder:

  1. A line in CLAUDE.md. "Dates in the UI use the format 24 Sep 2026." Cheap and usually enough.
  2. An example. When a rule keeps being misread, add one good and one bad example. Examples beat adjectives every time.
  3. A skill. When the correction is a whole procedure, save it as a skill so it runs the same way without you explaining it again.
  4. A test or hook. When the check is objective, turn it into code. Now it runs without you.
  5. Remove the gate. Only when the automated check has passed on real work for a good while, and one gate at a time.

When you remove a gate, pick the one that has not caught anything in weeks. The gate that annoys you most is usually the one still catching things.

Start with one agent

Your first agent should do one job, with read only tools, while you watch. The researcher above is a good start. Run it for a week, read everything it returns and note what you correct. Those corrections are your ladder. Once they are rules, examples and tests, you can add a second agent and trust both.

If you want to go further into patterns like pipelines and evaluator loops, Anthropic's Building effective agents is still the clearest write up I know. Read it after your first week, not before. It makes more sense once you have corrected an agent a few times yourself.

More in Agents

← All guides