Not every agent action should run unsupervised. When an agent is about to send an email, delete a record, execute a financial transaction, or perform any irreversible operation, you need a human to review and approve the action first. The Human-in-the-Loop (HITL) pattern lets your agent pause execution, present the pending action to the user, and resume only after explicit approval. Because HITL is built on LangGraph interrupts and checkpoints, the pause is durable. A user can refresh the page, a reviewer can answer from a different component, and the agent still resumes from the exact point where execution stopped instead of replaying the whole run.Documentation Index
Fetch the complete documentation index at: https://langchain-5e9cc07a-preview-cbuipl-1779916257-33d1bcf.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
How interrupts work
LangGraph agents support interrupts, explicit pause points where the agent yields control back to the client. When the agent hits an interrupt:- The agent stops executing and emits an interrupt payload
- The
useStreamhook surfaces the interrupt viastream.interrupt - Your UI renders a review card with approve/reject/edit options
- The user makes a decision
- Your code calls
stream.submit()with a resume command - The agent picks up where it left off
Setting up useStream
Connect useStream to your human-in-the-loop agent. When the graph hits an
interrupt, the hook exposes the pending payload on stream.interrupt. Render an
approval card while that value is set, then resume the run with
stream.submit(null, { command: { resume: response } }) after the user
approves, rejects, or edits the action.
The code examples use
useStream<typeof myAgent> for type-safe stream state. See Type inference for Python or JavaScript backends.The interrupt payload
When the agent pauses,stream.interrupt contains a HITLRequest with the
following structure:
| Property | Description |
|---|---|
actionRequests | Array of pending actions the agent wants to perform |
actionRequests[].name | The action name (e.g. "send_email", "delete_record") |
actionRequests[].args | Structured arguments for the action |
actionRequests[].description | Optional human-readable description of what the action does |
reviewConfigs | Per-action configuration controlling which decisions are allowed |
reviewConfigs[].allowedDecisions | Which buttons to show: "approve", "reject", "edit", "respond" |
Decision types
The HITL pattern supports four decision types:Approve
The user confirms the action should proceed as-is:Reject
The user denies the action with an optional reason:When an action is rejected, the agent receives the rejection reason and can
decide how to proceed. It may rephrase, ask clarifying questions, or abandon
the action entirely.
Edit
The user modifies the action’s arguments before approving:Respond
The user provides a direct reply for “ask user” style tools. Themessage becomes the tool result and the tool itself is not executed:
Use
respond when the tool is intentionally a placeholder for human input — for example, an ask_user tool that prompts the agent to collect information from the user.Building the ApprovalCard
Here is the decision wiring used by the approval cards. The UI can split each action into its own card, but the resume payload is a singleHITLResponse
with one decision per pending action:
The resume flow
After the user makes a decision, the full cycle looks like this:- Call
stream.submit(null, { command: { resume: hitlResponse } }) - The
useStreamhook sends the resume command to the LangGraph backend - The agent receives the
HITLResponseand continues execution. Each entry indecisionsmay be one of:{ type: "approve" }: The agent continues executing the action{ type: "reject", message }: The agent receives the rejection message and decides its next step{ type: "edit", editedAction }: The agent runs the tool with edited arguments{ type: "respond", message }: The human’s message is returned directly as the tool result without executing the tool
- The
interruptproperty resets tonullas the agent resumes streaming
Handling multiple pending actions
An interrupt can contain multipleactionRequests when the agent wants to
perform several actions at once. Render a card for each and collect all
decisions before resuming:
Best practices
Keep these guidelines in mind when implementing HITL workflows:- Show clear context. Always display what the agent wants to do and why. Include the action description and the full arguments.
- Make approve the easiest path. If the action looks correct, approving should be a single click. Reserve multi-step flows for reject/edit.
- Validate edited args. When users edit action arguments, validate the JSON structure before sending. Show inline errors for malformed input.
- Persist the interrupt state. If the user refreshes the page, the
interrupt should still be visible.
useStreamhandles this via the thread’s checkpoint. - Log all decisions. For audit trails, log every approve/reject/edit decision with timestamps and the user who made the decision.
- Set timeouts thoughtfully. Long-running agents should not block indefinitely on human review. Consider showing how long the agent has been waiting.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

