Choose when people intervene in agent actions

Learning objective

Decide where humans participate — approval before action, review after action, exception handling — by confidence, reversibility, and cost of error.

Core idea

Escalation triggers and structured handoffs establish when a case needs a person and what that person receives. This lesson adds an architectural decision: whether the person must intervene before an effect, can correct it afterwards, or handles only exceptions to an otherwise autonomous path.

Choose the intervention point for each business effect, rather than for the whole conversation. A reliable draft can propose an irreversible action. A reversible database edit can still expose confidential information before anyone reverses it. Confidence describes uncertainty; reversibility and error cost determine whether waiting for evidence is acceptable.

NIST AI RMF MAP 3.5 calls for defined, assessed, and documented human-oversight processes. Use an intervention register to implement that outcome: name each effect, its risk owner, the permitted review timing, and the conditions under which execution remains blocked. The register is a team artifact, not an Anthropic configuration file.

How it works

Classify the consequence before choosing the reviewer

Assess the proposed effect against three questions. How reliable is this decision on representative labeled cases? Can the effect actually be undone within the business’s correction window? What harm can occur before correction, including downstream actions that a rollback cannot retract?

Use those answers to select a pattern:

These are design criteria, not product defaults. A high empirical accuracy does not remove a mandatory approval. Conversely, a low-confidence draft that remains private may need revision rather than an executive approver. See 5.3.3 for routing precedence and 5.3.4 for the staffing implied by the selected pattern.

Document residual exposure explicitly. For “reversible,” name both the compensating operation and what it cannot recover. Deleting an internal note can remove the note; it cannot erase a decision another employee already made from it. If that consequence is material, move the checkpoint earlier or restrict who can consume the provisional result.

Match the control to the approval interval

In the Claude Agent SDK, the TypeScript canUseTool callback, or Python can_use_tool, handles runtime permission requests that reach it. A callback can wait for an in-session reviewer, pausing execution until it returns. That suits an operator who can inspect the proposed tool input immediately.

When waiting would outlive the process, a PreToolUse hook can return permissionDecision: "defer"; the tool does not execute, and the turn ends with stop_reason: "tool_deferred" for later session resumption. Claude Code honors this in non-interactive -p integrations, including Agent SDK applications, and only for a single tool call in the turn; with several calls, it ignores defer with a warning and continues normal permission evaluation. Persisted sessions remain subject to the cleanupPeriodDays retention sweep, which deletes session files after 30 days by default.

A permission callback is not sufficient for a check that must run on every call. The documented permission order evaluates hooks before deny rules, ask rules, permission mode, allow rules, and the callback. Earlier automatic approval can skip the callback. Put mandatory per-call checks in a PreToolUse hook. Its hookSpecificOutput can set hookEventName: "PreToolUse", permissionDecision: "deny", and permissionDecisionReason when trusted policy or approval state does not permit execution. A hook’s allow does not bypass applicable deny or ask rules.

For an approval that takes hours or crosses shifts, make the business service persist a pending proposal and release it only after review. An illustrative application tool named submit_change_for_review writes that proposal without performing the consequential action. The execution service checks the approved proposal version and the approver’s authority. Choose this application design when approval must outlive the agent session, remain auditable outside its transcript, and cover a business proposal rather than one deferred tool call. A tool permission and a business approval answer different questions.

Bind approval to what actually executes

Record an application-defined proposal identifier, revision, intended effect, target resource, reviewer, decision time, and approval expiry. If the agent changes the amount, recipient, or underlying evidence, invalidate the decision and request review of the changed proposal. Otherwise, a correct approval can authorize a different operation accidentally.

Before execution, recheck mutable business conditions. Approval of a proposed inventory adjustment does not establish that stock remains unchanged hours later. Keep rejected, expired, and unresolved outcomes distinct; none permits the action. NIST GOVERN 3.2 supports assigning these human and system responsibilities explicitly, rather than treating any available employee as an authorized approver.

An approval releases execution only for the proposal it covered, and only after mutable business conditions are rechecked.

Key distinctions and trade-offs

Approval prevents exposure while adding waiting time to every covered action. Retrospective review shortens the immediate path but spends a real risk allowance before correction. Exception handling concentrates scarce attention, but its coverage depends on the trigger design and accepted-path auditing.

Monitoring complements these patterns by identifying trends and enabling intervention. It cannot retrospectively prevent a particular irreversible effect. Similarly, sampling measures a population; it does not protect every unsampled case. Keep those purposes explicit when defending the intervention register to stakeholders.

Architecture / decision scenario

A retailer processes 8,000 inventory suggestions daily with a four-person operations team. Its illustrative policy permits automatic internal stock annotations, requires manager approval before supplier orders above $5,000, and routes conflicting warehouse counts to an inventory specialist. The operations owner accepts that an incorrect private annotation can persist until sampling or a user report detects it, then requires correction within two hours of detection. Supplier orders can trigger noncancelable production.

An architect proposes reviewing every suggestion after execution because validation shows 99% correctness. The operations owner rejects that alternative: a wrong supplier order can incur cost before review, and a passing average does not satisfy the approval policy.

The team uses retrospective sampling for private annotations with a staffed correction path, persists supplier orders as pending proposals, and handles conflicting counts as exceptions without changing stock. A PreToolUse hook denies protected order calls without the required approval state. Changes to quantity invalidate the stored decision. The operations owner accepts annotation exposure, the procurement manager owns order approval, and the specialist owns conflict resolution. Confidence influences review effort within these paths; it never grants purchasing authority.

Common exam traps

• Choosing review timing from model confidence alone.
• Calling an action reversible without accounting for harm before correction.
• Assuming canUseTool intercepts every call regardless of permission configuration.
• Treating submission to a review queue as approval to execute.
• Reusing an approval after changing the proposal it covered.

What to remember

Place a person before an effect when its error cost, reversibility, or governing policy requires prevention. Use retrospective review only with accepted exposure and a working correction path. Enforce exceptions and approvals at execution, and bind each decision to an owned, versioned proposal.

Knowledge check

References

• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• Anthropic, Configure permissions
• Anthropic, Control execution with hooks
• Anthropic, Handle approvals and user input
• Anthropic, Hooks reference