Choose where humans approve

Human approval is most useful at a transition where the workflow is about to create a consequence that automation cannot fully authorize. Approval at every step trains reviewers to click through. Approval after the side effect is too late.

The task is to find the few transitions where a person adds judgment or accepts responsibility, then give that person the evidence and control needed to make a real decision.

1. Map actions, not agent messages

List the state-changing actions in the workflow. Ignore drafting, planning, and internal tool calls unless they can affect another system or person.

read account history
draft refund request
validate amount against policy
issue refund
notify customer
record outcome

In this example, issuing the refund and sending the notification are the consequential actions. Reading history may still need access control, but it is not an approval point merely because an agent performs it.

For each action, name the last safe stop before execution.

2. Rate the consequence

Use concrete questions rather than a single risk label.

Question	Lower need for approval	Higher need for approval
Can the action be reversed completely?	Draft can be discarded	Payment cannot be recalled automatically
Who is affected?	Agent’s private workspace	Customer, employee, public audience, or third party
What is the maximum scope?	One bounded record	Many records or an open-ended query
Is policy deterministic?	Typed facts decide the rule	Context or intent changes the decision
Is the case familiar?	Covered by tested examples	New exception or conflicting evidence
What authority is exercised?	Read-only analysis	Money, identity, access, legal, or production change

Document the evidence behind each rating. “High risk” without a scenario does not tell a reviewer what to inspect.

3. Remove approvals that automation can own

Do not ask a person to recompute a deterministic rule. Put stable limits, required fields, role checks, and state checks in a policy gate.

Use automation when:

• the required facts come from authoritative systems;
• the rule can be expressed without subjective interpretation;
• allowed scope is bounded;
• failures stop safely;
• the decision and evidence can be recorded.

Keep human approval when the case requires judgment the gate does not encode, the policy names a human authority, or the consequence warrants explicit accountability.

4. Choose the transition to approve

Place approval immediately before the consequential action, after the workflow has assembled its proposal and evidence.

agent proposes action
    -> automated checks
    -> policy gate
    -> human approval, when required
    -> executor validates approval
    -> side effect

Avoid approving an early plan if the final amount, audience, target, or content can change afterward. Approve the exact action that the executor will perform.

Where several actions form one transaction, decide whether one approval can cover the bundle. Name every included action and reject execution if the bundle changes.

5. Define escalation rules

Write rules that route known cases without asking the agent to decide whether it deserves oversight.

approval_policy:
  auto_allow:
    - action: refund.create
      when: amount_minor <= 50000 and policy_gate == allow
  human_required:
    - when: amount_minor > 50000
      role: finance-approver
    - when: policy_gate == require_approval
      role: policy-owner
    - when: evidence_conflict == true
      role: workflow-owner
  stop:
    - when: policy_gate == deny
    - when: policy_gate == indeterminate and no escalation route exists

Thresholds in a real policy should come from the policy owner and use the system’s units. The values above only show the structure.

Include limits for repeated requests. An agent should not turn one denial into an approval by resubmitting until a different reviewer answers.

6. Design the review packet

Show the reviewer the proposed action, not a generic “approve” button. Include:

• the exact target, scope, and side effect;
• a human-readable preview or diff;
• the policy result and reason codes;
• evidence for each acceptance claim;
• known uncertainty and missing evidence;
• the result of approving and the result of rejecting;
• a stable request digest.

Keep the agent’s recommendation separate from observed facts. The reviewer may read the recommendation, but should not have to infer the amount, audience, or changed permissions from prose.

Give reviewers three responses when the workflow needs them:

APPROVE  authorize this exact request
REJECT   stop this request and record a reason
RETURN   request a specific correction without authorizing execution

Do not treat silence, timeout, or a closed browser window as approval.

7. Bind approval to execution

An approval should identify what was approved and who had authority to approve it.

{
  "approval_id": "approval-921",
  "request_digest": "sha256:...",
  "decision": "approve",
  "approver_role": "finance-approver",
  "policy_version": "refund-v4",
  "approved_at": "2026-08-13T11:10:00Z",
  "expires_at": "2026-08-13T11:20:00Z",
  "max_uses": 1
}

The executor should verify the request digest, role, expiry, policy version, and use count. If the request changes, ask for a new approval. Do not let the agent edit the approval record or call the side-effecting system with broader credentials.

8. Plan for reviewer unavailability

Choose behavior for timeouts before launch:

• wait with the request preserved;
• route to another person with the same defined authority;
• expire the request and require a fresh proposal;
• stop the workflow.

Do not silently downgrade to automatic execution. If delayed action creates its own harm, handle that with a narrow, pre-authorized policy path rather than an unbounded emergency bypass.

9. Verify the approval map

Test the decisions, the wiring, and the review screen.

1. Run a low-consequence case. Confirm it completes through the automated path without an unnecessary prompt.
2. Run each human-required condition. Confirm the correct role receives the exact request and evidence.
3. Reject a request. Confirm no side effect occurs and resubmission follows the rules you defined.
4. Change the request after approval. Confirm the digest mismatch blocks it.
5. Use an expired, consumed, or wrong-role approval. Confirm the executor rejects it.
6. Let the review time out. Confirm the request waits, reroutes, expires, or stops as specified.
7. Attempt the side effect directly with the agent identity. Confirm it lacks permission.
8. Review a sample of approved and rejected cases. Check whether reviewers had enough evidence and whether any approval point produces routine click-through.

Common failure modes

Approval happens before the request is final

The agent gets approval for a plan, then changes the target or content. Bind approval to the final request digest and invalidate it after any change.

The reviewer sees only the agent’s summary

Provide source facts, diffs, policy results, and evidence references. A summary can help orientation but should not be the only basis for the decision.

Every action asks for approval

Move deterministic checks into policy gates and keep drafts private. Reserve people for consequential transitions, exceptions, and unresolved conflicts.

Approval is advisory

If the executor accepts a request without the approval artifact, the prompt is ceremonial. Enforce approval at the credential or execution boundary.

One approval authorizes future actions

Broad standing approval hides scope changes. Use a bounded subject, digest, expiry, and use count. Create a separate policy for genuinely recurring work.

Reviewers cannot reject safely

Define what rejection and return do to the workflow. Preserve the proposal and evidence without executing the side effect, and record the reason.

Related reading

• Your agent should not be its own reviewer
• A passing test is not always a good result
• Two-plane loop
• Closure test