Human checkpoints without human bottlenecks

01 · The purpose

A checkpoint should add judgment the system cannot supply.

Human-in-the-loop is often treated as a universal safety answer. Put a person before every tool call and the agent cannot act alone. In practice, this creates a new failure mode: routine work queues behind people who lack time or context, approvals become habitual, and the nominal control turns into a button that everyone clicks.

A useful checkpoint has a reason. The person may own a business decision, interpret ambiguous intent, assess a novel risk, accept an irreversible effect, or choose among legitimate tradeoffs. If a deterministic policy can decide safely, encode the policy. If an automated verifier can prove the condition, run it. Save scarce human attention for judgment.

This framing also improves accountability. The human is not asked to bless the agent in general. The human decides one explicit action under a known policy with the evidence available at that time.

Approval is a risk control, not a progress ritual.

02 · Placement

Put checkpoints at effect boundaries.

Review should happen after the agent has done the cheap, reversible work and before it crosses a consequential boundary. Let the agent search, analyze, draft, simulate, test, and prepare. Pause before it sends, purchases, deletes, deploys, grants access, commits a legal position, or changes a customer-visible record.

OpenAI's description of Codex controls separates the sandbox from approval policy. The sandbox limits where the agent can operate; approval governs requests to cross that boundary. This is a useful general model. It keeps ordinary work fast inside known limits and makes exceptional authority explicit.

Risk is not only the tool name. The same tool may be safe or sensitive depending on arguments. Sending an internal draft to one test address differs from sending a campaign to 100,000 customers. Deleting a disposable preview differs from deleting a production database. Approval rules should inspect the intended effect.

03 · The review packet

Make the decision inspectable in one screen.

A reviewer should not reconstruct the run from a transcript. The system should present a compact decision packet. It must say what will happen, why the action is proposed, what evidence supports it, which systems and people will be affected, whether it can be reversed, and what uncertainty remains.

Show the exact tool and parsed arguments for external actions. Summarize the diff for file or configuration changes. Link to full evidence, but do not force every reviewer to read it. Include policy checks and independent verification results. If a check did not run, say so.

Offer meaningful decisions: approve once, reject with a reason, request a change, or approve a constrained class for the rest of this run. Avoid a vague approve button with no effect preview. The reviewer must know what authority is being granted.

04 · Durable pause

An approval should wait without holding a process hostage.

Important reviewers are not always online. A system that keeps one server request open while it waits will fail under ordinary delays. Persist the run state, pending action, evidence packet, policy version, and approval identity. Release the compute. Resume from the same checkpoint when a valid decision arrives.

The OpenAI Agents SDK implements this pattern with interruptions and serializable run state: a tool call can pause before execution, the application can approve or reject it, and the run can resume later. The exact SDK is optional. The durable-state property is not.

Approvals need expiry and concurrency rules. If the target changed after review—for example, the branch advanced or the customer record was edited—the old approval may no longer apply. Bind the decision to resource versions or hashes. Re-evaluate policy and input guardrails immediately before execution.

Rejection is useful input, not an exception to swallow. Return the reason to the workflow, preserve it in the trace, and let the agent revise only if policy permits. Repeated requests for the same rejected action should stop or escalate, not wear the reviewer down.

05 · Queue design

Operate approval as a service with an explicit budget.

Every checkpoint creates a queue. Define who owns it, which time zone covers it, the expected response time, what happens on expiry, and which cases may be delegated. High-severity production work may need a fast on-call path. A content publication may wait for the next business day. The workflow should know the difference.

Batch decisions only when the actions share the same context and risk. Ten low-risk file edits in one proposed patch are easier to review together. Ten unrelated customer refunds are not. A batch should show its total effect and let the reviewer inspect outliers.

Route by expertise as well as availability. Security approves a new outbound domain. Finance approves a payment threshold. A service owner approves a production rollout. A generic manager queue is fast to create and slow to trust.

Set a human-attention budget per completed outcome. If a low-risk workflow needs three approvals and twelve minutes of review, the agent may be moving work rather than removing it. Redesign the policy or the tool boundary before adding more automation.

06 · Metrics

Measure whether review changes outcomes.

Approval rate alone is not a success metric. A 99% approval rate may mean the agent is excellent. It may also mean the checkpoint adds no value. Sample approved actions and compare them with policy and later outcomes. Inspect what reviewers change, reject, or send back.

Track false escalations, missed escalations, median and p95 wait time, review time, rejection and revision rates, incidents after approval, and the share of approvals that contain substantive feedback. Segment by action class, risk, team, and policy version.

Use the findings to remove checkpoints as well as add them. When an action class has stable evidence, low impact, strong automated checks, and a proven rollback, permit it within a bounded policy. When incidents cluster around a supposedly safe path, narrow the authority or improve the evidence packet.

07 · Rollout

Start restrictive, then automate the decisions you understand.

List every external effect in the workflow. Classify impact, reversibility, evidence quality, and accountable owner. Make high-impact boundaries impossible to cross without the right identity. Run the remaining actions in observe-only mode and compare the policy's proposed decisions with real reviewers.

After the policy is calibrated, allow low-risk actions inside explicit limits. Keep logs and sample them. Add automatic verification before medium-risk actions and preserve rollback. Retain human approval for novel, ambiguous, or hard-to-reverse decisions.

1. Define the effect classes and the person accountable for each one.
2. Create a versioned policy that can inspect tool arguments and current state.
3. Build the review packet and test it with real reviewers before launch.
4. Persist interruption state, bind approval to resource versions, and set expiry.
5. Measure queue time, decision changes, misses, false alarms, and incidents.
6. Replace proven routine approvals with bounded standing rules; keep sampling outcomes.