When should an AI agent pause for approval?

• The approved pattern is to pause at checkpoints or when the agent hits a blocker — never after every tool call.
• Pausing constantly turns a helpful agent into a babysitter: users start clicking Approve without reading, and the gate stops meaning anything.
• An always-visible status keeps the user oriented between gates, so the occasional pause lands as a deliberate beat instead of a surprise.

“Agents can then pause for human feedback at checkpoints or when encountering blockers.”

Source: Anthropic — Building effective agents ↗

• The gate is about consequences, not confidence: money, credentials, deletions, publishing — anything with a real-world side effect needs a human in the loop.
• Routine, reversible actions such as reading a file, searching or drafting should never require approval; friction that adds nothing trains users to ignore it.
• Scope the pause to the one sensitive call rather than the whole task, so the human decision stays small and specific.

“Use the human-in-the-loop (HITL) flow to pause agent execution until a person approves or rejects sensitive tool calls.”

Source: OpenAI — Agents SDK: Human in the loop ↗

npm run migrate -- --env=production --confirm

• The approval prompt must name the concrete action — the tool, its arguments, the command that will run.
• A paraphrase invites rubber-stamping; the exact proposal lets the human actually audit before they click.
• Surface the details inside the request itself: the human should not have to expand a menu to see what they are approving.

“If the approval rule requires approval and no decision for that tool call is stored, execution pauses, and RunResult.interruptions (or RunResultStreaming.interruptions) contains ToolApprovalItem entries with details such as agent.name, tool_name, and arguments.”

Source: OpenAI — Agents SDK: Human in the loop ↗

• Pre-approval is a convenience, not a blank check — a sign of risk re-raises the gate even for actions the user already allowlisted.
• Suspicious commands, dangerous paths and unknown binaries should ask again no matter what the user approved before.
• The asymmetry is deliberate: err toward asking when the stakes are real, and toward trusting when they are not.

“Suspicious bash commands require manual approval even if previously allowlisted”

Source: Claude Code docs — Security ↗

npm run migrate -- --env=production --confirm

• Responsibility lives with the human, so what gets reviewed must be the actual code and commands — not a summary of what the agent intends.
• Make the review surface the working artifact — diff, command, payload — so approval is an informed yes.
• The approve action should feel like a decision, not a formality: one explicit control, with the consequence named.

“You’re responsible for reviewing proposed code and commands for safety before approval.”

Source: Claude Code docs — Security ↗

npm run migrate -- --env=production --confirm

• When the agent interrupts you is a setting, not a fixed behavior — users should tune how often they are asked.
• A run mode that asks more or less lets each user pick the autonomy level that fits the task at hand.
• Default to asking, and let the user relax the gate for trusted, repeatable work.

“Run Modes control how the Cursor agent runs tool calls, and when Cursor interrupts you for approval.”

Source: Cursor docs — Run Modes ↗

npm run migrate -- --env=production --confirm

• Pause when the action is irreversible, has real-world side effects, or could misrepresent the user — approve everything else automatically.
• When you do pause, show the exact action, name the consequence, and keep Approve and Deny one click apart.
• Pre-approval lowers friction; risk re-raises it. When in doubt, ask.