Human approval belongs where an agent can create an external commitment, change account direction, or answer under uncertainty. Define the boundary for each action, then have the agent recommend before it executes. Use two gates: a confidence gate routes uncertain work to a person,1 while a policy gate requires approval for certain action types regardless of confidence.2 This keeps review focused on decisions that need judgment and leaves routine work inside a written allowance. The handoff should be predictable enough for the agent to explain why it paused.
| Stage | What you are trying to learn | Example question |
|---|---|---|
| Set the boundary | what the agent can do without review | What can this action change? |
| Apply the gates | whether policy or uncertainty stops execution | Does this action always need approval? |
| Route the conversation | whether the reply or context needs a person | What did the prospect actually ask? |
| Review the action | what decision the reviewer should make | Is the proposed action safe and within scope? |
| Record and release | whether the decision and reason are captured | What must be logged before execution? |
Set the boundary
Start with an action inventory. Describe each action, its scope, the system it can affect, and the point where a person takes over.
List permitted actions explicitly.3 For each capability, set a risk boundary that shows when the action needs blocking, escalation, or extra verification.4 Keep the allowance specific enough to inspect. A broad instruction such as "handle outreach" gives a reviewer nothing useful to approve.
Separate routine handling from judgment calls. An agent can research accounts, qualify leads, monitor signals, and draft messages, while a human decides whether to retire an outbound sequence, its strategy, and its attribution.5 Keep those decisions in the review lane even when the preparatory work runs automatically.
Apply the gates
Once the boundary is written, run every proposal through the same sequence. The policy check asks whether the action type always needs a person. The confidence check asks whether this case has enough support to proceed.
Put a recommendation step between analysis and execution. At the Recommend stage, the agent proposes an action with its reasoning and a human approves it.6 Show the proposed action, supporting context, and requested approval in one place. Continue only when the reviewer can tell exactly what will happen after approval.
Set the confidence threshold before the agent handles live work. If the threshold changes from case to case, escalation becomes a personal judgment call and review volume is hard to predict. The agent should pause when its conclusion falls below the agreed threshold, while policy still controls action types that always require approval.
Route the conversation
Build the handoff around the reply and the agent's uncertainty. Timing can inform review, but the conversation's content determines whether a person needs to take over.
A human should take over when a prospect replies.7 Objections and low-confidence replies route to a human for review.8 Set the handoff before launch, then test it with replies containing objections, unclear intent, or a request the agent cannot answer from its approved context.
Treat silence as a separate state. During a long sales cycle, silence can be the normal pace of internal consensus-building.9 Keep the account in its existing state until a defined signal supports escalation. This prevents the agent from turning a quiet account into an unnecessary sequence change.
Review the action
Review should establish whether the proposed action is within scope and whether its consequences fit the approval rule. Give the reviewer enough context to decide without reconstructing the agent's work.
For connected capabilities, ask: "Is user presence required? Is the scope necessary? Can user consent be limited to low-risk permissions and verified publishers?"10 These questions expose approval requests that are too broad or lack a clear reason to involve a person.
Require manual approval when an action exceeds a defined cost threshold.11 Actions such as approving a large payment, deleting production data, or granting new access warrant human review before they proceed.12 If an agent touches production systems, build a human escalation path for it.13 For infrastructure or resource deletion, use multiple reviews and maintain rollback capability for every agent action.14
Record and release
A decision is usable later only when the team can see what was proposed, what happened, and why. Keep the record close to the approval event so a later reviewer can follow the chain without relying on memory.
The reviewer can view, deny, or block an approval request.15 If the requested permissions are appropriate, the request can be approved.16 Give each outcome a clear status, then release the action only after that status is recorded.
Document the reason for approving or denying the request and any subsequent adjustments.17 The record should also show the proposed action, the scope reviewed, and the resulting change. This gives the next reviewer a usable handoff when an action returns for inspection.
What not to do
Use these checks before granting the agent a new action or widening an existing boundary.
- Do not let a proactive suggestion execute before the user approves it.18
- Do not leave repetitive work without a person who owns quality.19
- Do not permit an unreviewed action to pause the wrong campaign, send the wrong email to the wrong customer, or merge the wrong pull request.20
Put the action inventory, two gates, conversation handoff, and review record into the operating procedure before autonomous execution begins. Test each boundary with a proposal that should pass and one that should pause, then make the agent show its reasoning and approval state before it acts.