Pause an AI Agent for Human Approval with LangGraph interrupt()

Asking a model to 'check with the user before sending' is a request, not a control. A model can forget, be talked out of it, or misjudge what counts as risky. A real approval gate sits in your code, outside the model: the run stops at a defined point, nothing downstream can happen until a person decides, and the decision is recorded.

That has three consequences. The run must be able to stop for hours or days without holding a server open. It must be able to continue later from exactly the same state. And the pause must be something the model cannot skip. LangGraph's interrupt() is built for this, and this guide shows how it behaves, which rules you must follow, and what you still have to design yourself.

The details below come from the LangGraph documentation, checked on 10 November 2026. LangGraph moves quickly, and some newer APIs, such as event streaming and typed response schemas, have version requirements, so check the docs for the version you run. To see how LangGraph compares with the OpenAI, Microsoft, CrewAI, Bedrock and Temporal approaches, read Human-in-the-Loop AI Agent Frameworks Compared. For the wider design question of where to put approvals at all, read Designing Human-in-the-Loop AI Agents for Business Workflows and Agentic Workflows: Human in the Loop or Fully Autonomous.

Calling interrupt() inside a graph node does five things, per the documentation:

1. Execution suspends at exactly that point.
2. The graph state is saved through the checkpointer.
3. The value you passed to interrupt() is returned to whoever invoked the graph, under __interrupt__ with the default invoke call, or on the interrupts property when using event streaming.
4. The graph waits indefinitely.
5. When you resume, the value you supply becomes the return value of the interrupt() call inside the node.

To use it you need three things: a checkpointer that persists state, a thread ID in the run configuration that tells LangGraph which saved state to load, and an interrupt() call whose payload is JSON-serializable. The thread ID is effectively your cursor. Reusing it resumes the same checkpoint, and a new value starts a fresh run with empty state.

Unlike static breakpoints, which pause before or after named nodes, interrupt() is dynamic. You can place it anywhere in your code and make it conditional, for example pausing only when a refund exceeds a limit. LangGraph's own documentation says static breakpoints are meant for debugging and are not recommended for human-in-the-loop workflows.

This example gates a refund. The approval node pauses with the details a reviewer needs and routes to one of two nodes based on the answer. It is adapted from the pattern in the LangGraph documentation, with a business scenario added.

from typing import Literal, TypedDict

from langgraph.checkpoint.memory import InMemorySaver  # use a durable saver in production
from langgraph.graph import END, START, StateGraph
from langgraph.types import Command, interrupt


class RefundState(TypedDict):
    order_id: str
    amount: float
    reason: str
    status: str


def request_approval(state: RefundState) -> Command[Literal["issue_refund", "decline"]]:
    decision = interrupt({
        "question": "Approve this refund?",
        "order_id": state["order_id"],
        "amount": state["amount"],
        "reason": state["reason"],
    })
    return Command(goto="issue_refund" if decision["approved"] else "decline")


def issue_refund(state: RefundState):
    # The side effect lives AFTER the approval, in its own node
    return {"status": "refunded"}


def decline(state: RefundState):
    return {"status": "declined"}


builder = StateGraph(RefundState)
builder.add_node("request_approval", request_approval)
builder.add_node("issue_refund", issue_refund)
builder.add_node("decline", decline)
builder.add_edge(START, "request_approval")
builder.add_edge("issue_refund", END)
builder.add_edge("decline", END)

graph = builder.compile(checkpointer=InMemorySaver())

The refund itself sits in a separate node after the gate. That is deliberate and it matters for a reason covered below: the node containing interrupt() runs again on resume, so you do not want the irreversible action in the same node.

from langgraph.types import Command

config = {"configurable": {"thread_id": "refund-order-8841"}}

# First run: reaches interrupt() and pauses
result = graph.invoke(
    {"order_id": "8841", "amount": 240.0, "reason": "Damaged on arrival", "status": "pending"},
    config,
)
pending = result["__interrupt__"][0].value   # the payload for your approval UI

# ...hours later, a reviewer decides. Resume on the SAME thread_id:
final = graph.invoke(Command(resume={"approved": True}), config)
print(final["status"])   # refunded

Three details from the documentation are easy to get wrong. You must use the same thread ID on resume. The value in Command(resume=...) becomes what interrupt() returns, and it can be any JSON-serializable value. And Command(resume=...) is the only Command pattern meant to be passed as input to invoke or stream. The update, goto and graph options are for returning from nodes, so do not use them to continue a conversation.

Store the thread ID alongside your own business record, such as the refund request or ticket, so that when a person clicks Approve in your interface you can find the right paused run.

When you resume, LangGraph does not continue from the line after interrupt(). It restarts the whole node from the beginning, and interrupt() then returns the value you supplied. Everything above the interrupt() call in that node runs a second time.

That is harmless for reading data. It is dangerous for anything with a side effect. Suppose a node creates an audit record, then calls interrupt(), then continues. Each resume creates another audit record. If it sends a message, the message goes out again. This is the most common way an approval step ends up causing the duplicate action it was meant to prevent.

Approval does not remove the need for care afterwards. Even after approval, retries can repeat a side effect if a node fails after committing it, so the documentation recommends idempotent operations or deduplicating writes in the external system. For payments and similar actions, pass an idempotency key derived from the request, so a second attempt is recognised and ignored.

A plain yes or no is often not enough. Reviewers frequently want to fix a draft or change an amount rather than reject the whole action. LangGraph supports this by letting the resume value carry edits, and you can put the interrupt directly inside a tool so approval travels with the tool wherever it is used.

from langchain.tools import tool
from langgraph.types import interrupt


@tool
def send_customer_email(to: str, subject: str, body: str):
    """Send an email to a customer."""
    response = interrupt({
        "action": "send_customer_email",
        "to": to,
        "subject": subject,
        "body": body,
        "message": "Approve sending this email?",
    })

    if response.get("action") == "approve":
        # The reviewer may have edited any field
        final_to = response.get("to", to)
        final_subject = response.get("subject", subject)
        final_body = response.get("body", body)
        return deliver(final_to, final_subject, final_body)   # your sending code

    return "Email cancelled by reviewer"

Resume with {"action": "approve"} to send as drafted, with extra keys to send an edited version, or with any other action to cancel. The model sees the tool result and carries on, so a rejection is information it can use, for example by offering the customer a different answer.

Notice that the sending code runs only after the interrupt returns. That respects the restart rule, because nothing irreversible happens before the pause.

The payload you pass to interrupt() is what the reviewer sees, so it decides whether approvals are quick and correct or slow and rubber-stamped. This part is design judgement from our own builds rather than anything LangGraph prescribes.

Resist the urge to send everything. A reviewer who has to read a page to approve a small change will approve without reading. Show the decision and the evidence, and link to the rest.

If you use LangGraph 1.2.12 or later, the interrupt() call also accepts a response_schema, a Pydantic model, TypedDict or dataclass describing the answer expected on resume. The resume value is then validated, and invalid input raises a validation error you can retry with the same thread ID. It is a clean way to stop a reviewer interface from sending malformed decisions.

The documentation is clear that the graph waits indefinitely and that interrupt payloads are returned to the caller. It does not mention notification, deadlines, approver identity or audit trails, and we found no built-in feature for them in the pages we read. That is our reading of those pages, so check the current documentation, but plan on building these yourself:

• Notification: something must tell a person that a request is waiting, whether a message, an email, a task in a queue or a screen in your own tool.
• Expiry and escalation: decide what happens if nobody answers in four hours. Common answers are reminding, escalating to someone else, or cancelling safely.
• Approver identity and permission: check that the person resuming the run is allowed to approve this action and amount, and record who they are.
• Audit: store the request, the payload shown, the decision, who made it and when, in your own system of record, not only in checkpoints.
• Concurrency: if two people click Approve at once, make sure only one resume goes through, for example by tracking request status in your own database.

A tidy structure is to keep an approval request table in your database, with the thread ID, status, payload, deadline and decision. Your interface reads and writes that table. A small service resumes the graph when a decision lands. The graph itself stays simple.

Every pending approval is a checkpoint. If the checkpoint store is lost, the approval is lost, and the run cannot be resumed. For durability modes, replay traps, encryption and retention, see AI Agent Checkpointing Explained.

Two practical notes from the persistence documentation. With the Postgres saver, thread IDs are stored in a limited-length column, so keep them under 255 characters and use a UUID or a hash if you need a deterministic one. And checkpoints accumulate over time, which increases latency and storage cost, so set a retention policy or a cleanup job. Decide up front how long a paused approval may live, and delete the checkpoints after that.

If parallel branches of a graph each call interrupt(), the run can pause with more than one pending interrupt. Each has an ID. The documentation shows resuming them in a single call by passing a dictionary that maps each interrupt ID to its answer. Use this when one request genuinely needs several independent decisions, such as legal and finance both signing off. Keep the mapping in your approval table so you know which decision belongs to which interrupt.

1. Run to the pause and assert the payload contains what a reviewer needs and nothing secret.
2. Resume with approve, reject and edit, and assert each path ends in the right state.
3. Kill and restart the process while paused, using a durable checkpointer, then resume and confirm it still works.
4. Resume twice with the same decision and confirm the side effect happens once.
5. Put a counter in any code placed before interrupt() during testing, to confirm you understand how often it runs.
6. Let a request expire and confirm the fallback behaves safely.

These tests are cheap and they catch exactly the failures that cost money: lost approvals, duplicate actions and requests nobody ever answered.

• A durable checkpointer is configured, with a retention policy.
• Thread IDs are unique, under 255 characters, and stored with your business record.
• Nothing irreversible happens before interrupt() in the same node.
• interrupt() is not inside a bare try/except or a loop.
• The reviewer sees the action, the reason, the evidence and the risk.
• Approvers are authenticated, and permitted for the action and amount.
• Requests have an owner, a deadline and an escalation path.
• Every request and decision is written to your own audit store.
• Actions after approval use idempotency keys.

For the wider build, see Building Production-Ready AI Agents with LangGraph and How to Build Human-in-the-Loop AI Agents That Teams Actually Trust. If you want approval steps designed into an agent for your own workflow, see our agentic workflow orchestration service.