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. ```text 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. ```text 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. ```yaml 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: ```text 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. ```json { "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](/notes/control-loop/your-agent-should-not-be-its-own-reviewer) - [A passing test is not always a good result](/notes/control-loop/a-passing-test-is-not-a-good-result) - [Two-plane loop](/reference/two-plane-loop) - [Closure test](/reference/closure-test)