Search⌘ K
AI Features

Human-In-The-Loop Approvals

Explore how to implement human-in-the-loop approval processes within LangGraph workflows. Understand risk assessment, drafting, routing, and conditional branching to handle high-risk requests. Gain hands-on experience in building conditional review gates that pause AI workflows for human decisions, improving accuracy and compliance in real-world AI systems.

Language models generate plausible text. For general questions about features, shipping times, or account settings, that is usually good enough. But for responses that touch legal obligations, financial commitments, compliance requirements, or policy exceptions, plausible is not enough. A confidently worded but incorrect response about a legal clause or a refund exception can cause real harm.

The standard engineering response to this is a review gate: before any high-risk draft reaches the user, a human reads it and makes an explicit approve or reject decision. If approved, the response is finalized and delivered. If rejected, the request is escalated to a specialist instead of delivering a potentially incorrect answer.

This lesson builds that pattern. We will classify requests by risk level, generate a draft for all of them, route high-risk drafts through an approval gate, and branch to finalization or escalation based on the reviewer’s decision. The same state fields, approval node, and branching logic apply whether the reviewer’s decision is entered through a UI, an API call, or a simulated value as we do here.

How reviewer decisions enter the graph

In a production human-in-the-loop system, the graph pauses at the approval node. The draft is presented to a reviewer through an interface. The reviewer enters a decision, and the graph resumes from that node with the updated state. LangGraph supports this through its persistence and checkpointing infrastructure.

In this lesson, we simulate the reviewer’s decision by including a reviewer_decision field in the initial state, set at invocation time. This lets us exercise the full approval pattern, risk assessment, drafting, the approval gate, and both branches, without setting up persistence infrastructure. The graph structure, state fields, and branching logic are exactly what a production implementation uses.

The simulation is honest: reviewer_decision in real systems is written by a human after seeing the draft. In our simulation, it is written by the caller before the graph runs. The approval gate node is the same in both cases: it reads reviewer_decision and writes a normalized approved boolean.

The two-stage branching pattern

This workflow has two conditional decision points. Understanding both is key to understanding the pattern.

  • The first decision happens after drafting. The routing function checks whether the request was classified as high-risk. If it was, the draft goes to the approval gate. If not, the draft goes directly to finalization. Low-risk and medium-risk requests never involve a reviewer.

  • The second decision happens after the approval gate. The routing function checks whether the reviewer approved the draft. Approval leads to finalization. Rejection leads to escalation.

The table below maps each decision point to the state field it reads and ...