LangGraph interrupt() or HumanInTheLoopMiddleware: which to use for tool approval

The short answer

For approving tool calls in a LangChain agent, use HumanInTheLoopMiddleware. It checks each tool call against a per-tool policy and interrupts when review is needed, and the reviewer can approve, edit, reject or respond.¹ Use LangGraph’s interrupt() directly when the pause isn’t about a tool call: a custom approval step, a question to the user mid-workflow, a review of a draft.²

Both need a checkpointer and a thread ID, because the paused state has to be saved and found again.¹² And both inherit one LangGraph rule worth knowing before you ship: when you resume, the paused node restarts from the beginning. We tested what that does to a side effect.

The middleware: approval per tool

You configure interrupt_on with an entry per tool. Each value is True (interrupt with the default config), False (auto-approve) or a config object listing the allowed decisions.¹

The four decisions:¹

To continue after an interrupt, you invoke again with a Command carrying the decisions, for example resume={"decisions": [{"type": "approve"}]}, on the same thread ID.¹

A sketch of the configuration, following the docs’ names:

Code Program code, for developers. The text around it says what it does.

from langchain.agents import create_agent
from langchain.agents.middleware import HumanInTheLoopMiddleware
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model=model,
    tools=[search_orders, refund_order, delete_customer],
    middleware=[HumanInTheLoopMiddleware(interrupt_on={
        "search_orders": False,
        "refund_order": {"allowed_decisions": ["approve", "edit", "reject"]},
        "delete_customer": {"allowed_decisions": ["reject"]},
    })],
    checkpointer=InMemorySaver(),
)

Read-only tools are auto-approved, refunds can be approved or corrected, and customer deletion can only be refused from this agent. Treat this as a sketch to check against the docs for your installed version; we didn’t run it against a live model.

The edit decision deserves a policy of its own. A reviewer who changes a refund from 250 to 25 has made a decision the agent didn’t, and your logs should show both the proposed and the final arguments.

interrupt(): the primitive

interrupt() pauses graph execution, saves the state and returns a value to the caller; you resume by invoking the graph again with Command(resume=...), and the resume value becomes the return value of interrupt().² The middleware is built on the same persistence layer.¹

The docs list rules for using it:²

• Side effects before interrupt must be idempotent, because the node restarts from the beginning on resume.
• Don’t wrap interrupt in try/except, or you catch the signal and the pause never reaches the graph.
• Don’t reorder interrupt calls within a node; resume values are matched by position.
• Use a durable checkpointer in production, and a thread ID so the runtime knows which state to resume.

The re-run trap, tested

We installed LangGraph 1.2.17 in a scratch environment and wrote a one-node graph that records a “refund requested” email, then asks for approval:

Code Program code, for developers. The text around it says what it does.

emails_sent = []

def refund_node(state: S):
    emails_sent.append("refund requested")          # side effect BEFORE interrupt
    decision = interrupt({"question": f"Approve refund of {state['amount']}?"})
    if decision != "approve":
        return {"result": "rejected"}
    return {"result": f"refunded {state['amount']}"}

Compiled with InMemorySaver, run once, then resumed with Command(resume="approve") on the same thread:

Code What the screen or file shows, copied as is.

after first invoke: {'question': 'Approve refund of 250?'} | emails: 1
after resume: refunded 250 | emails: 2

Two emails for one refund. The node ran up to the interrupt, paused, then ran again from the top when resumed. Every resume adds another. In real code, that line might send a Slack message, write an audit row, call a webhook or, worst, start the refund.

The fixes, in order of preference:

1. Put side effects after interrupt(), so they run once, on the resumed pass.
2. Split into two nodes: one that asks, one that acts.
3. Make the side effect idempotent, keyed by something stable such as the thread ID and step, if it must come first.

The middleware avoids this for the tool itself: the tool runs after the decision. Your own nodes around it are still subject to the rule.

Side by side

Production notes

• Durable checkpointer. InMemorySaver loses paused runs on restart. A paused approval that waits overnight needs a database-backed checkpointer, which the docs advise for production.²
• Thread IDs are identity. Whoever can resume a thread can approve its tool calls. Don’t let one user resume another’s thread.
• Rules belong outside the prompt. “Ask before refunds” in the system prompt isn’t the middleware. Config in code is. For rules that also hold for other clients, a gateway in front of the tools does the same job; our post on policy languages for tool calls compares the options.
• Record decisions. Who approved, what they changed in edit, and why they rejected. That’s your audit trail for each human-in-the-loop approval.

A checklist

• Tool approvals use HumanInTheLoopMiddleware with an explicit entry per tool.
• Read-only tools False; writes with approve, edit, reject; destructive tools reject only, or removed.
• A durable checkpointer, and thread IDs scoped to one user.
• No side effects before interrupt() in custom nodes, or they’re idempotent.
• No interrupt() inside try/except.
• Decisions logged with the reviewer and any edited arguments.

For the same pattern in the Vercel AI SDK, see toolApproval, tested. To see what the agents configured on your machine can change without a prompt, paste the config into the check page or run npx deedglass scan (how the grade works); to try approval rules in your browser, open the playground.

Written with AI assistance and checked against our claims register.