An approval checkpoint needs to identify a specific action and the evidence a person needs to judge it. A request to approve the next step is incomplete if the step can change after approval. Write checkpoints around observable changes, with enough context that the reviewer can decide without rerunning the investigation.
This guide proposes a practical format for your own use cases. The linked deployments show why particular boundaries matter. They do not establish that a prompt alone can enforce those boundaries. Pair the instructions with scoped tools and credentials that match the authority you intend to grant.
Name the change that needs approval
Start with the external effect. Examples include updating one firewall rule, paying one supplier, publishing one document or merging one code change. State the resource, destination and allowed scope. A permission to inspect a repository does not by itself specify whether an agent may publish the contents elsewhere.
Separate preparation from execution in the task description. Allow the agent to inspect inputs, reproduce a problem, compare options and create a proposed artifact within the workspace. Require approval when the proposal crosses the chosen boundary. The reviewer then approves a concrete result rather than an unfinished plan.
The reviewer then approves a concrete result rather than an unfinished plan.
Willison's Cloudflare account records an expiring token and a switch from MCP to direct API access. Our use case entry turns that operational account into a prompt that pauses before the proposed PATCH.
Specify the evidence package
For a configuration edit, ask for the current value, proposed value, resource identifier and rollback. Include checks for both intended behavior and a nearby behavior that should remain valid. For a search challenge, that means showing which request patterns receive the challenge and which remain usable.
For a supplier purchase, ask for the exact item, quantity, vendor, currency, total cost and delivery assumptions. Include links to the pages used to establish those facts. Distinguish a quoted price from an estimate. A reviewer cannot approve a reliable budget when shipping or tax remains hidden in prose.
For publication, show the final artifact and destination. State whether the action creates a draft, changes a public page or sends a message to an audience. Give the reviewer a stable version to inspect. If the artifact changes after approval, request approval for the revised version.
Put authority into the tools
Remove capabilities the task does not need. A supplier comparison can use read access without a payment interface. A code agent can prepare a branch without access to deployment credentials. A research agent can inspect approved documents without a tool that emails them to other people.
In Project Vend's second phase, the researchers withheld a payment interface so purchases required human checks. The account still describes significant manipulation and support needs. That combination is useful evidence for a narrow boundary, not proof that the entire shop was safe.
Keep credentials scoped to the resource and lifetime required for the approved action. Where your system supports it, let a separate executor hold the credential. Have the agent submit the proposed action to that executor. Avoid exposing broad secrets merely because the agent needs one narrow operation.
Write the checkpoint request
Use a short, repeatable format. The following is an editorial template you can adapt:
Approval required before [external action].
Prepare the final proposed change first.
Show the target resource, current state and proposed state.
Include the evidence, expected effect, checks and rollback.
Identify unresolved facts that could change the decision.
Ask the designated approver to authorize this exact proposal.
If the proposal or target changes, seek fresh approval.
Do not treat silence, elapsed time or a failed check as approval.
Choose a designated approver whose authority matches the consequence. A technical reviewer may approve a patch while a business owner approves a purchase. Record that distinction in the use case configuration. Avoid asking whichever person happens to reply first when the action needs a particular owner's decision.
Limit the approval's lifetime
A quote can expire, inventory can change and a production resource can drift. Specify conditions that invalidate the approval. For a configuration edit, compare the current value with the value the reviewer inspected immediately before applying the change. If they differ, stop and present the updated proposal.
For a paid action, invalidate approval when the vendor, quantity or total changes beyond the accepted limit. For a public artifact, tie approval to a revision or content hash. Choose an identifier the system can verify, rather than asking the agent to remember whether the text feels unchanged.
Avoid treating a successful earlier run as permanent permission for every later run. A recurring use case can have a standing policy, but the policy still needs explicit limits. Write the allowed destinations, amounts and conditions where a reviewer must intervene.
Test the boundary with a harmless run
Use a sandbox resource or a draft-only destination. Give the agent a task that reaches the checkpoint. Inspect the request and confirm that execution waits. Then approve the exact proposal and verify the resulting state. Record both the approval event and the external effect.
Test a changed proposal as well. After approval, alter the target resource or input and confirm that the use case notices. Also test rejection and missing information. The expected result is a clear report with no external action. A system that only succeeds on the happy path has not demonstrated the checkpoint.
Test retries deliberately. A timeout after a purchase request does not reveal whether the vendor accepted it. Require the executor to check the transaction's identity before retrying. Make repeated requests converge to one approved effect, and keep the evidence needed to investigate ambiguous outcomes.
Review exceptions as changes to policy
If the agent repeatedly reaches a checkpoint for harmless actions, narrow the checkpoint definition or grant a specific standing permission. Avoid training the reviewer to approve unread requests. If a supposedly harmless action gains new consequences, move it back behind review.
The audio sandbox migration offers another boundary to borrow: its final design kept storage credentials with the orchestrator and gave the job signed URLs. Inspect the linked implementation before adapting that separation to your system.
Keep the policy near the use case and update it when tools change. Review an actual execution record, including failures and rejected actions. The useful checkpoint is the one that gives the reviewer a clear decision and limits the executor to the authority that decision grants.