A misplaced approval gate can let a rejected tool call run or repeat an approved action. Human-in-the-loop authorization for AI agents means a consequential tool call waits for an authorized person to approve its exact action and final arguments. These approval and resume checks help you verify that the decision still governs what happens after the pause.
Approve one action instance: the tool, target, final arguments and execution context. A human decision must reach the application's execution boundary before the action runs. LangGraph supplies a checkpointed interrupt; your application must enforce the approver's rights, reject stale decisions and handle duplicate attempts. The six-row acceptance matrix below turns those responsibilities into tests. Runtime mechanics are attributed to official documentation; the acceptance criteria are editorial recommendations for your implementation.
What is the person authorizing?
The person authorizes a specific operation under a defined scope. A prompt such as “May I handle this account?” leaves the agent free to choose the operation and arguments afterwards. Show the actual action before asking for a decision.
For an account change, the review record should identify the tenant and account, the tool name, all final arguments, the requesting identity, and the action revision. Include the effect and relevant policy context so the reviewer can decide whether they have authority. For an outbound message, show the recipient and message content. A permitted read can still disclose sensitive data, so “read-only” alone is insufficient grounds to skip review.
Our recommended decision rules are:
- If the tool, target, tenant or arguments change after approval, stop dispatch and request review of the new revision. A reviewer may edit and approve together if the interface clearly shows the final values being authorized.
- If the decision has expired, the reviewer lost permission or the target record changed in a way that invalidates the decision, stop and reassess. Choose expiry and record-version rules for the workflow; there is no universal safe duration.
- If two workers receive the same approval, only one may claim it for execution. Enforce that transition in durable application state.
Human-in-the-loop describes the blocking decision here. Human-on-the-loop describes monitoring while the agent acts. Training-data labeling and review after delivery serve other purposes; neither prevents this pending tool call from executing.
For the wider editorial collection, browse OnlineSummit intelligence and agentic AI talks.
How does the runtime pause and resume?
In LangGraph, interrupt(payload) pauses the node and saves state through a checkpointer. Resume with Command(resume=decision) and the same thread_id; the interrupted node starts again from its first line. The decision becomes the interrupt's return value (LangGraph interrupts).
Use persistent checkpoint storage for restart recovery. LangGraph's persistence documentation distinguishes checkpoints for a single thread from stores shared across threads, and states that in-memory checkpoints disappear when the process restarts. Saving a conversation or review notification is not a substitute for saving the paused execution state.
OpenAI Agents SDK uses its own continuation model. Its official guardrails and human review guide describes tool-approval interruptions and resumable state: the application approves or rejects pending items and resumes that state. For delayed review, serialize and store it. Re-derive restart tests from the SDK you deploy; LangGraph's node-restart rule is not a cross-platform API guarantee.
The approval-and-resume acceptance matrix
Accept a gate only after the execution boundary and retained records satisfy these six checks. Run them against a mock or sandbox service before using real account changes, messages or payments. Every pass condition below is an application acceptance recommendation, including those motivated by documented runtime behavior.
| Check | Required condition | Failure test and prevention | Evidence to keep |
|---|---|---|---|
| Check1. Action and arguments | Required condition Execution uses the reviewed tool, tenant, target and final arguments, bound to one action revision. | Failure test and prevention Approve revision v1, then alter the target or arguments before dispatch. Expect zero side effects and fresh review. Separately test a reviewer edit that is explicitly approved. Compare execution against the immutable final snapshot. | Evidence to keep Proposed and final snapshots, revision, reviewer edit, dispatched arguments. |
| Check2. Approver and decision | Required condition Only a reviewer with permission for this tenant and action can decide; the decision is valid and still current. | Failure test and prevention Submit malformed input, use another tenant's reviewer, revoke a role while paused, and send an expired decision. Each attempt must block execution. Validate identity and decision schema on the server, then recheck authority at dispatch. | Evidence to keep Reviewer identity, relevant role or policy version, expiry, decision and denial reason. Keep secrets out of routine logs. |
| Check3. Rejection path | Required condition Rejecting the action prevents its external side effect, and the agent receives an explicit cancellation result. | Failure test and prevention Reject, then let the agent continue. Assert zero calls at the mutating service boundary for the rejected action. A re-proposed action must receive a new review. Route rejection to cancellation before the tool executes. | Evidence to keep Rejected revision, cancellation result, service-call count and any later proposal's separate decision. |
| Check4. Persisted state | Required condition Restart restores the correct paused action and decision context without treating a new run as the approved continuation. | Failure test and prevention Pause, terminate the worker and restore from persistent state. Try the correct run identifier, then an unrelated one. Only the matching continuation may proceed after validation. Refuse missing, corrupt or expired state. | Evidence to keep Run/thread ID, checkpoint or serialized-state reference, action revision and recovery result. |
| Check5. Replay and duplicate dispatch | Required condition Repeated code does not repeat a business effect; one approval cannot launch duplicate operations. | Failure test and prevention Count pre-interrupt effects across resume. Submit the decision concurrently, then simulate a lost tool response and retry. Use atomic decision consumption and the downstream service's documented idempotency or reconciliation mechanism. | Evidence to keep Attempt count, effect count, stable operation ID, downstream receipt and deduplication or reconciliation result. |
| Check6. Audit artifacts | Required condition You can connect the approved revision to the decision and its actual outcome, including an unresolved outcome. | Failure test and prevention Exercise approve, edit, reject and restart. Reconcile each decision with execution attempts and service receipts. Deduplicate decision records; preserve distinct retry attempts. Mark a missing result as unknown until checked. | Evidence to keep Decision ID, run/interrupt ID, reviewer, timestamps, final snapshot, attempts and result or pending reconciliation. Protect sensitive payloads with access controls and retention rules. |
For parallel LangGraph interrupts, the docs pair responses with interrupt IDs. That routing identifier helps match answers; the application still decides whether a reviewer may answer. LangGraph also documents typed response validation and distinguishes it from an unvalidated JSON Schema dictionary. Check the installed version before using response_schema (documented requirement: langgraph>=1.2.12).
The audit fields support the same investigation as the agent observability session record: use the related record for further reading, and retain your own decision-to-result evidence.
Why can resume repeat a side effect?
LangGraph repeats code above interrupt() when the node restarts. A non-idempotent insert there can create a second row. The official interrupts guide recommends idempotent operations, moving effects after the pause or separating them into nodes; it also warns against swallowing the interrupt exception and changing interrupt order.
Moving a tool below the decision fixes its placement relative to review. You still need a recovery plan if the external service completes the action but the worker loses the response. Before retrying, inspect the service receipt or reconcile using its supported operation identifier. An application-side “sent” flag cannot by itself resolve that gap across two systems.
Use a stable idempotency key only where the downstream API documents its scope and retry behavior. If the service offers no safe duplicate check, leave the outcome unresolved and escalate for reconciliation instead of blindly repeating an irreversible action. This is an application design recommendation, not a guarantee supplied by an interrupt.
Worked example: accepting a disable-user gate
Assume a sandbox agent proposes disable_user(user_id="u_4821", reason="chargeback dispute") in tenant t_example. Assign action revision v1 and show the full snapshot to an authorized support reviewer. These are illustrative inputs and expected assertions, not reported test results.
- Approve v1 without changes. Expect one business effect on u_4821 and a matching service receipt.
- Let the reviewer change the reason to “fraud review,” then explicitly approve the displayed final revision. Assert that the service receives that reason and the audit retains the original and final values.
- Reject v1. Expect zero disable calls. Verify that a later proposal cannot reuse that rejection as permission.
- Approve v1, then change the target to u_9000 outside review. Expect zero effects and a new review request for v2.
- Restart while paused. Restore the same pending action, then validate the reviewer and snapshot before continuing. An unrelated thread must not execute it.
- Deliver the same decision to two workers. Expect one claim of the decision; then simulate the account service completing the disable operation while its response is lost. Verify the downstream receipt or documented retry contract before another attempt.
For a deduplicating sandbox service, record duplicate effects = completed business effects − distinct approved operations. With assumed inputs of two delivery attempts for one approved operation and one completed effect, 1 − 1 = 0 duplicate effects. A result of two completed effects would yield 2 − 1 = 1 and fail. Count the service's effects, not just requests or “approved” log entries; those arithmetic examples are acceptance expectations, not measurements.
What should you check before adopting the matrix?
Start with the runtime version and the tool's actual execution boundary. Rework the persistence and replay tests for any platform other than the documented LangGraph flow. SDK approvals, debugging breakpoints, automated guardrails and human review have different semantics.
Review capacity also matters. Track queue age, time to decision and cancellations so an overloaded inbox does not turn review into habitual approval. Include checkpoint storage, reviewer time, incident reconciliation and audit retention in your operating-cost assessment. No fixed cost or latency estimate follows from the presence of a gate. Our agent supervision session record is related reading on that operational question.
Sources and method
Official documentation was retrieved on 18 October 2026:
- LangGraph interrupts: pause/resume mechanics, node replay, decision schemas and parallel interrupt routing.
- LangGraph persistence: thread checkpoints, stores and loss of in-memory checkpoints on process restart.
- OpenAI Agents SDK guardrails and human review: approval interruptions and resumable state, used only for that SDK's continuation model.
The matrix, snapshot rules and failure-injection cases are editorial engineering recommendations derived from these control boundaries. The worked example specifies hypothetical test inputs and pass conditions. Linked summit records are further reading; this article uses no speaker quotations or session claims as evidence and provides no compliance certification.
Check the official sources against the version you deploy, use our methodology and editorial policy to inspect the sourcing standard, and report an error with the affected claim and source if it needs correction.
Updated 18 October 2026.