How to Design Human-in-the-Loop Checkpoints for Autonomous AI Agents

Build a Human-in-the-Loop AI Agent with LangGraph India's Most Futuristic AI Conference Is Back – Bigger, Sharper, Bolder d : h : m : s Career GenAI Prompt Engg ChatGPT LLM Langchain RAG AI Agents Machine Learning Deep Learning GenAI Tools LLMOps Python NLP SQL AIML Projects Reading list How to Become a Data Analyst in 2025: A Complete RoadMap A Comprehensive Learning Path to Tableau in 2025 A Comprehensive NLP Learning Path 2025 Learning Path to Become a Data Scientist in 2025 Step-by-Step Roadmap to Become a Data Engineer in 2025 A Comprehensive MLOps Learning Path: 2025 Edition Roadmap to Become an AI Engineer in 2025 A Comprehensive Learning Path to Master Computer Vision in 2025 Best Roadmap to Learn Generative AI in 2025 GenAI Roadmap for Enterprises Large Language Models Demystified: A Beginner’s Roadmap Learning Path to Become a Prompt Engineering Specialist How to Design Human-in-the-Loop Checkpoints for Autonomous AI Agents Janvi Kumari Last Updated : 11 Oct, 2026 19 min read Autonomous AI agents can read requests, retrieve data, reason through options, and trigger actions in seconds. That speed is useful, but it also creates risk when the next step affects money, customer records, or external systems. Human-in-the-loop checkpoints add control at the moment an agent’s recommendation is about to become a real-world action. In this article, we’ll build a LangGraph refund agent that investigates a request, proposes a refund, pauses for human approval, and only executes the action after review. Table of contents What Is a Human-in-the-Loop Checkpoint? When Should an Agent Ask for Approval? How the Refund Agent Workflow Works Prerequisites Create Mock Order Data Create the Order Lookup Tool Define the Refund Proposal Structure Create the LLM and Build the Refund Agent Run the Agent Investigation Convert the Investigation into a Structured Refund Proposal Create the Refund Tool Define the LangGraph State Create the Agent Node Add the Human Approval Checkpoint Route the Approval Decision Create the Refund Execution and Rejection Nodes Build the Complete LangGraph Workflow Add a Checkpointer and Compile the Graph Run the Workflow and Pause for Approval Resume the Workflow After Human Review Test the Workflow End to End Move the Workflow Toward Production Conclusion Frequently Asked Questions What Is a Human-in-the-Loop Checkpoint? A human-in-the-loop checkpoint is a deliberate pause inside an AI workflow before the agent performs an action that could have meaningful consequences. The agent can continue working autonomously up to that point. It may understand the request, retrieve information, call tools, and prepare a recommendation. But before executing a sensitive action, the workflow stops and asks a person to review the proposal. A useful review step should clearly show: What the agent wants to do Why it chose that action What information supports the decision What will happen if the action is approved The timing of the checkpoint is critical. If an agent sends an email, updates a customer account, or issues a refund and asks for approval afterward, the review is no longer useful. The checkpoint must happen before execution. In LangGraph, this can be implemented using interrupt(). The graph pauses at that point, stores its state through a checkpointer, and waits for an external decision before continuing. Conceptually: This separates two important responsibilities. The agent decides what it recommends. The application controls whether that recommendation is allowed to become a real-world action. When Should an Agent Ask for Approval? Not every action performed by an AI agent needs human approval. If an agent is only reading information, searching for a knowledge base, or preparing a draft, human intervention may add unnecessary friction. But once the agent is about to change data, contact a customer, move money, or perform another consequential action, a review step can become valuable. A simple way to think about it is to separate low-risk actions from actions that affect the outside world. Agent action Example Possible checkpoint Read information Search a knowledge base Usually no approval Retrieve data Check an order status Usually no approval Prepare content Draft a customer response Review before sending Change a record Update customer information Approval based on impact Financial action Issue a refund Approval before execution Destructive action Delete data Approval before execution For our refund agent, retrieving an order is a read-only action, so the agent can do it autonomously. Issuing the refund is different because it changes a financial state. That is where we place the human checkpoint. The basic principle is: Low-risk action → Agent can continue High-impact action → Human review before execution Each organization should define these boundaries based on its own policies, risk tolerance, and the consequences of an incorrect action. How the Refund Agent Workflow Works Before writing the code, let’s understand how the complete refund workflow operates. The process has four main stages: Prepare, Review, Decide, and Act. 1. Prepare The customer sends a refund request in natural language. The LLM agent reads the request and determines whether additional information is required. If an order ID is available, the agent calls the get_order tool to retrieve verified details such as the product, amount, delivery status, and refund status. Using the customer request and the retrieved order information, the agent prepares a structured refund proposal. 2. Review The proposal is passed to a human approval checkpoint. Instead of immediately executing the refund, LangGraph pauses the workflow using interrupt(). The reviewer can inspect the proposed refund amount, order ID, and the reason provided by the agent. 3. Decide The reviewer approves or rejects the proposal. If the request is approved, the workflow continues to the refund execution step. If it is rejected, the workflow ends without calling the refund tool. 4. Act Only an approved request reaches the issue_refund tool. The tool performs the mock refund and returns the result. This separation is important. The LLM is responsible for investigation and reasoning, while the application and human reviewer control whether a consequential action is executed. This architecture allows the agent to work autonomously during investigation while placing human oversight exactly where the workflow begins to affect the outside world. Prerequisites Before we start building the refund agent, make sure you have the following: Python 3.10 or later An OpenAI API key Basic familiarity with Python Basic understanding of LLM agents and tool calling Install the required libraries: pip install -U langchain langgraph langchain-openai pydantic We’ll use: langchain to define tools and create the agent langchain-openai to connect the agent to an OpenAI model langgraph to orchestrate the workflow and pause it for human approval pydantic to define the structured refund proposal Set your OpenAI API key before running the code. On macOS or Linux: export OPENAI_API_KEY="your-api-key" On Windows PowerShell: $env:OPENAI_API_KEY="your-api-key" Once the environment is ready, we can start by creating the mock order data that our agent will inspect. 1: Create Mock Order Data We’ll begin with a small in-memory order store, so the agent has something to inspect. ORDERS = { "ORD-1024": { "product": "Wireless Headphones", "amount": 79.99, "status": "delivered", "refunded": False }, "ORD-2048": { "product": "Mechanical Keyboard", "amount": 119.00, "status": "delivered", "refunded": False } } Each order contains four fields: product: the item purchased amount: the amount that could be refunded status: the current order status refunded: whether the order has already been refunded For this tutorial, we keep everything in memory so the example is easy to run. In a production system, the same information would usually come from a database, commerce platform, CRM, or internal order API. The important point is that the agent should not invent order information. It should retrieve verified data through a tool. In the next step, we’ll create that tool. 2: Create the Order Lookup Tool Now we’ll create a read-only tool that lets the agent retrieve verified order information. from langchain.tools import tool @tool def get_order(order_id: str) -> dict: """Retrieve order details for a given order ID.""" order = ORDERS.get(order_id) if not order: return { "found": False, "order_id": order_id } return { "found": True, "order_id": order_id, **order } The @tool decorator makes the function available to the LLM agent. The docstring also matters: “””Retrieve order details for a given order ID.””” The model uses this description to understand what the tool does and when it should call it. For example, if the customer says: My order ID is ORD-1024 and the headphones arrived damaged. the agent can identify the order ID and decide that it needs more information before making a recommendation. It can then call: get_order("ORD-1024") and receive: { "found": true, "order_id": "ORD-1024", "product": "Wireless Headphones", "amount": 79.99, "status": "delivered", "refunded": false } This is an important part of the agent design. The LLM does not guess the product, price, or order status. It retrieves that information from a controlled source. The get_order tool is also read-only. It can inspect data, but it cannot change anything. That makes it suitable for autonomous use by the agent. In the next step, we’ll define the structure of the refund proposal that the agent will produce. 3: Define the Refund Proposal Structure The agent should not return an unstructured paragraph that we later need to parse. Instead, we’ll define a structured refund proposal using Pydantic. from pydantic import BaseModel, Field from typing import Literal class RefundProposal(BaseModel): order_id: str = Field( description="The order being evaluated" ) action: Literal["refund", "no_refund"] = Field( description="Whether a refund should be proposed" ) refund_amount: float = Field( description="Refund amount. Use 0 if no refund is proposed." ) reason: str = Field( description="Short explanation for the recommendation" ) This gives the agent a predictable output format. For example: { "order_id": "ORD-1024", "action": "refund", "refund_amount": 79.99, "reason": "The customer reported receiving a damaged product." } Structured output helps the rest of the workflow because each value can be accessed directly. For example: proposal["order_id"] proposal["refund_amount"] proposal["action"] proposal["reason"] This is much more reliable than extracting values from free-form text. It also makes the human approval step easier because the application can display the exact order ID, proposed amount, and reason to the reviewer. In the next step, we’ll create the LLM and use it to build the real tool-using refund agent. 4: Create the LLM and Build the Refund Agent Now we can create the actual LLM-powered agent. First, initialize the model: from langchain_openai import ChatOpenAI model = ChatOpenAI( model="gpt-4.1-mini", temperature=0 ) We use a low temperature because the workflow benefits from more predictable responses. Next, create the agent: from langchain.agents import create_agent refund_agent = create_agent( model=model, tools=[get_order], system_prompt=""" You are a customer support refund agent. Your job is to investigate refund requests. If an order ID is available, use the get_order tool to verify the order before making a recommendation. Never invent order information. Use the customer request and verified order details to decide whether a refund should be proposed. Do not issue refunds yo [truncated for AI cost control]