Where a person gets to say no

An agent that never stops to check is only as safe as its worst guess. Anthropic’s guidance on building agents says they should “pause for human feedback at checkpoints or when encountering blockers”, and carry “stopping conditions (such as a maximum number of iterations) to maintain control.” That leaves the practical question of where the pauses go. There are four kinds, and the last is different from the rest.

Plan first, or just do it

Claude Code has a mode for the first kind of pause:

Plan mode tells Claude to research and propose changes without making them. Claude reads files, runs shell commands to explore, and writes a plan, but does not edit your source.

Claude Code docs, Permission modes

Enter it with Shift+Tab, by prefixing a single prompt with /plan, or from the start with claude --permission-mode plan. Edits stay blocked until you approve the plan, and the approval itself is a choice about how much oversight comes next:

Whether a change deserves that pause comes down to four things about it.

Direct, planned, or phased

	Direct executionJust ask	Plan modeAgree the approach first	Multi-phaseA gate between stages
Scope	One file, or one contained change	Several files, or a reach nobody has mapped yet	Work that divides into stages
If it goes wrong	Easy to undo, and tests will say so	Costly to unpick once written	Some stages cannot be undone at all
Approach	Obvious	Uncertain, or several reasonable designs	Known in outline, checked at each stage
Sign-off	The diff is the review	Someone should see the approach before code exists	A person approves before each irreversible step
Example	Fix a typo in an error message	Replace the authentication middleware	Rename a database column three services read

Gate what cannot be undone

Multi-phase work is plan mode’s idea applied more than once. The column rename from the table might run like this:

Shaded: the one stage that cannot be taken back.

The gate that matters most is the one immediately before the irreversible stage, not one at the very end. A review after the old column is gone can only report the damage. Everything before that point can be retried, so it needs checking, not permission.

The third kind of pause guards against a different failure: an agent that is not doing anything irreversible, only failing repeatedly. A maximum number of iterations turns “keep trying” into “stop and report”, and the same approach failing twice is exactly the kind of blocker the guidance says should bring a person in.

When a person asks for a person

The last pause is the only one the designer does not schedule. Claude’s customer support guide treats getting escalation right as a quality to measure, suggesting you track “the percentage of correctly escalated conversations versus those that should have been escalated but weren’t” and aim for 95% or higher.

It does not settle the harder design question, so here is the rule we would hold an agent to. An explicit request for a human ends the attempt. The agent may well be able to solve the problem, and it should still hand over, with a summary so the person does not have to explain everything again. Solving it anyway overrides a choice the customer has already made. Short of an explicit request, escalation is a judgement about what the agent can actually resolve.

A good handover summary is a brief in the sense of part 2: what the customer wants, what the agent tried, what it found, and what is still open. The person picking it up has not seen the conversation either.

Try it

Decide where the pause goes, if anywhere, before opening each one.

The whole method

1. Act directly when the change is small, reversible and obvious.
2. Plan first when it is wide, costly to unpick, uncertain, or needs someone’s sign-off.
3. Put a gate immediately before anything irreversible, and a limit on every loop.
4. A request for a human ends the attempt. Hand over with a summary.

Sources: Anthropic Engineering, Building effective agents; the Claude Code documentation on permission modes; Claude’s customer support agent guide. The escalation rule is our recommendation, not a quotation. Checked September 2026.

More on this

• Give the task the shape it already has — Most agent designs go wrong by imposing a structure the work does not have. Draw the dependencies and the pattern names itself.
• A subagent knows only its brief — Whatever the brief leaves out, the subagent has to guess.
• Your MCP server is a prompt — Tool descriptions, resource lists and error messages all end up in front of the model. When Claude picks the wrong tool, the fix is usually in text the server wrote.