How it works
An approval checkpoint turns a risky transition into an explicit protocol. The harness does not merely ask a person whether the agent should continue. It records what the agent intends to do, stops execution at a durable boundary, and waits for a decision from an authorized reviewer.
A reliable checkpoint usually follows this sequence:
- The agent prepares a proposed action without performing it.
- The harness captures the action, relevant inputs, expected effects, permission scope, and current workflow state.
- Execution enters a durable waiting state. No dependent action may cross the boundary.
- A reviewer approves, rejects, edits, or requests a new proposal.
- The harness records the decision and resumes from the saved state under the approved constraints.
The approval should bind to a specific proposal. If the command, payload, target, credentials, or surrounding state changes after review, the approval is stale and the harness should request another decision. Otherwise, a harmless-looking approval can become authority for materially different work.
The checkpoint also needs an explicit timeout and cancellation path. Silence is not approval. A timed-out request should remain stopped or enter a defined recovery state rather than quietly continuing.
Why it matters in an agent harness
Approval checkpoints place human judgment at transitions where deterministic rules cannot fully express acceptable risk. Common examples include publishing content, sending an external message, modifying production data, spending money, widening permissions, or executing an irreversible operation. The model can prepare the work, but authority to create the external effect remains separate.
That separation improves control only when the review surface is legible. A person cannot meaningfully approve a vague summary such as “apply the changes.” The harness should expose the exact target, intended mutation, relevant diff, permission scope, expected result, and known uncertainty. Review becomes ceremonial when the operator must reconstruct the proposal from a long transcript.
Checkpoint placement is a design decision. Too few checkpoints allow errors to propagate beyond a recoverable boundary. Too many interrupt routine work, increase coordination cost, and train operators to approve requests without inspection. I prefer checkpoints at changes in authority or blast radius, not at every model turn. Read-only retrieval may run autonomously, while publishing the resulting artifact may require approval.
A checkpoint also creates a useful failure-containment boundary. Before approval, the proposed action should have no external side effect. After approval, the harness should execute only the reviewed action and record its outcome. If the result is unknown because of a timeout or transport failure, the system must reconcile state before retrying. Repeating an approved action blindly can duplicate messages, payments, or mutations.
Finally, approvals are part of the execution record. The record should identify who decided, what they saw, which proposal version they approved, when the decision occurred, and what happened afterward. This supports debugging and evaluation without treating human approval as proof that the agent’s work was correct.
Approval checkpoint vs approval gate
The terms are often used interchangeably, but a useful engineering distinction is that the gate defines the authorization rule while the checkpoint implements the runtime pause and state transition.
| Axis | Approval checkpoint | Approval gate |
|---|---|---|
| Primary concern | Execution state | Decision policy |
| Main question | Where and how does work pause? | Under what conditions may work proceed? |
| Required machinery | Durable state, proposal binding, resume path | Reviewer rules, risk criteria, authorization scope |
| Typical failure | Resuming stale or incomplete work | Applying the wrong policy or accepting an unauthorized decision |
A gate can decide that no human review is required for a low-risk action. A checkpoint exists only when execution actually stops for approval. Keeping the concepts separate helps teams test policy decisions independently from pause-and-resume reliability.
The Rifty take
We optimize for sparse, consequential checkpoints with high-information review surfaces. We accept a small delay at genuine authority boundaries, but we do not treat human attention as a substitute for permissions, deterministic checks, or reversible execution. Approval grants bounded authority to perform one reviewed transition; it does not certify the entire run.
Implementation checks
- Define the exact transition that requires approval and the risk it contains.
- Persist authoritative workflow state before presenting the request.
- Show the proposed mutation, target, scope, uncertainty, and expected effect.
- Bind the decision to an immutable proposal identifier or content digest.
- Invalidate approval when relevant inputs, permissions, or state change.
- Authenticate the reviewer and verify that they can authorize this action.
- Support explicit approve, reject, revise, cancel, and timeout outcomes.
- Prevent downstream work from running while the checkpoint is unresolved.
- Make resume idempotent, or reconcile external state before any retry.
- Record the proposal, reviewer, decision, constraints, and execution result.
- Test process restarts, duplicate decisions, stale approvals, and unknown outcomes.
- Remove checkpoints that operators cannot evaluate meaningfully or routinely approve without inspection.
Frequently asked questions
Which agent actions should require an approval checkpoint?
Require one when an action changes authority, creates an external effect, exposes sensitive data, spends resources, or is difficult to reverse. Placement should follow blast radius rather than model uncertainty alone. Routine, bounded, reversible actions are usually better controlled through permissions, limits, and automated verification.
What information should an approval request show?
Show the exact proposed action, target, material inputs, expected effect, permission scope, relevant diff, and known uncertainty. The reviewer should not need to reconstruct intent from an agent transcript. If the proposal changes after presentation, invalidate the request and generate a new approval decision.
Does human approval make an agent action safe?
No. Approval supplies bounded authorization, not proof of correctness or safety. The harness still needs scoped permissions, deterministic validation, execution limits, observability, and recovery behavior. Human review is valuable where judgment matters, but it can fail through ambiguity, fatigue, missing context, or an illegible review surface.
How should a harness resume after approval?
Resume from persisted authoritative state and execute only the proposal version that was reviewed. The resume operation should be idempotent or reconcile external state before retrying. If the target, payload, credentials, or preconditions changed while waiting, stop and request a fresh approval.
What should happen when an approval request times out?
A timeout should produce an explicit stopped, cancelled, or escalated state defined by the workflow contract. It must never imply consent. The harness should retain enough state to resume safely after a later decision or terminate cleanly without leaving locks, reservations, or partial actions behind.