How do Human-in-the-Loop agents work?

Human-in-the-Loop agents are AI agents that stop at important moments and ask a human to check, approve, edit, or answer before they continue. The agent does most of the work by itself, but a person stays in control of the decisions that matter.

In this blog, we will learn about how Human-in-the-Loop agents work. We will also see why a fully automatic agent is risky, the points where a human can step in, how an agent pauses and continues after the human replies, how to decide which actions need a human, and where this approach works well and where it slows us down.

We will cover the following:

• The problem with fully automatic agents
• What is a Human-in-the-Loop agent?
• Where can a human step in?
• How does a Human-in-the-Loop agent work?
• How does the agent pause and continue?
• A simple code example
• Which actions need a human?
• Common mistakes
• Advantages and disadvantages

I am Amit Shekhar, Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

I teach AI and Machine Learning at Outcome School.

Let's get started.

The problem with fully automatic agents

An AI agent is a system built around an LLM that works in a loop: it thinks about the goal, picks a tool, looks at the result, and repeats until the job is done. The LLM asks for a tool, like send_email or book_flight, and our code runs it.

Let's say we tell an agent, "Book me a flight to Mumbai for next Friday." The agent searches flights, compares prices, picks one, and books it. In a fully automatic agent, nobody checks these steps.

But an agent can make mistakes, and it makes them fast.

Suppose the agent misunderstands "next Friday" and books the wrong date. Or it picks a flight that costs 5 times more than we wanted. Or it sends an email to the wrong customer. Or it deletes a file that we needed.

Some mistakes are small and easy to undo. Others cost money, hurt trust, or cannot be undone at all.

So, the following issues arise with a fully automatic agent:

• It can take wrong actions that cannot be undone.
• It can guess when it must ask.
• It can do something that is against company rules.
• Nobody is responsible for the final decision.

We need a solution where the agent still does most of the work, but a human checks the important parts. So, here comes the Human-in-the-Loop agent to the rescue.

What is a Human-in-the-Loop agent?

A Human-in-the-Loop agent is an AI agent that pauses at chosen points and waits for a human to approve, edit, reject, or answer before it continues.

Here, a human is placed inside the agent's loop as one of the steps. People often write it as HITL in short.

Think of a junior employee and a manager. The junior does the research, fills in the forms, and prepares everything. But before signing a big contract or spending a large amount of money, the junior goes to the manager and says, "Here is what I plan to do. Can you approve it?". The manager says yes, says no, or makes a small change.

The agent is the junior. We are the manager.

The agent does not ask about everything. That would waste the manager's time. It asks only at the important moments.

Planning your move into AI?

No matter which tech domain you work in today, with your effort, you can transition to these roles:

• AI Engineer
• Forward Deployed Engineer
• AI Agent Engineer
• Harness Engineer
• Voice AI Engineer
• AI Architect
• LLM Engineer
• LLM Inference Engineer
• Gen AI Engineer
• MLOps Engineer
• ML Engineer
• Deep Learning Engineer

Our AI and Machine Learning Program at Outcome School takes you there.

Where can a human step in?

Now, let's see the common points where a human joins the loop.

Approve before an action: The agent prepares an action, like "send this email" or "pay 20,000 rupees", and waits. The human can approve it, reject it, or edit it first. This is the most common pattern.

Answer a question: When the agent is not sure, it asks instead of guessing. For example, "You said next Friday. Do you mean 9th October or 16th October?"

Review the output: The agent writes a draft, like a report or a reply to a customer, and a human reviews it before it goes out.

Take over when stuck: If the agent fails again and again, or the case is unusual, it hands the task to a human. This is called escalation, which means passing the problem to someone with more authority.

Give feedback: The human says what was good or bad, and this feedback is used to improve the agent later.

Let me tabulate these points for your better understanding.

How does a Human-in-the-Loop agent work?

Let's take the flight example and see it step by step.

Step 1: The agent works by itself. It searches flights and compares prices. These are safe actions because they only read data and change nothing. No human is needed here.

Step 2: The agent reaches a risky action. It wants to call the book_flight tool, which spends money. Our code has marked this tool as "needs approval".

Step 3: The agent pauses. Instead of running the tool, our system stops the loop and creates an approval request. It shows the human exactly what the agent wants to do: "Book flight AB-203, Friday 9th October, 7:00 AM, price 5,400 rupees."

Step 4: The human decides. The human can approve, reject with a reason, or edit the details, like changing the time to the evening flight.

Step 5: The agent continues. If approved, the tool runs. If edited, the tool runs with the new details. If rejected, the agent receives the reason and tries another way, or stops.

We can picture this as below:

          +----------------------+
          |    Search flights    |
          |     (safe, auto)     |
          +----------------------+
                     ↓
          +----------------------+
          |    Compare prices    |
          |     (safe, auto)     |
          +----------------------+
                     ↓
          +----------------------+
          |    Wants to book     |
          |       (risky)        |
          +----------------------+
                     ↓
          +----------------------+
          |   PAUSE: ask human   |
          +----------------------+
                     ↓
      +--------------+--------------+
      ↓              ↓              ↓
   Approve         Edit          Reject
      ↓              ↓              ↓
   Book as       Book with     Tell agent
   planned        changes      the reason

Here, we can see that the safe steps run automatically, and only the risky step goes to the human.

A quick note for you

No matter which tech domain you work in, get familiar with these topics:

• LLM
• RAG
• MCP
• Agent
• Fine-tuning
• Quantization

We put it all together in one video:

AI Engineering Explained: LLM, RAG, MCP, Agent, Fine-Tuning, and Quantization

No need to stop reading - bookmark it and watch later when you get time. Future you will thank you.

Now, let's get back to the topic.

How does the agent pause and continue?

Now, the next big question is: how does a program "wait" for a human? A human can take 2 seconds or 2 days to reply.

We cannot keep the program running and waiting for 2 days. The server can restart, and we would lose everything.

So, the answer is saving the state. The state is everything the agent knows at this moment: the goal, the steps done so far, the tool results, and the action it wants to take next.

It works as below:

• When the agent pauses, the system saves the full state to a database. This saved copy is called a checkpoint.
• The system sends the approval request to the human, for example as a button in a chat app, an email, or a task in a dashboard.
• The program can now stop completely. Nothing is lost, because the checkpoint is safe in the database.
• When the human replies, the system loads the checkpoint, adds the human's answer, and continues the loop from exactly where it stopped.

Think of it like a bookmark in a book. We stop reading, put the bookmark, and close the book. Days later, we open the book at the bookmark and continue from the same line.

We have a detailed blog on Graph Engineering that explains how checkpoints let an AI system pause and resume step by step.

Popular agent frameworks support this directly. For example, LangGraph has an interrupt function that pauses the agent and saves a checkpoint, and the agent is resumed later with the human's answer.

The idea looks like below:

from langgraph.types import interrupt, Command

def booking_step(state):
    decision = interrupt({"action": "book_flight",
                          "details": state["chosen_flight"]})
    if decision == "approve":
        book_flight(state["chosen_flight"])
    return state

# Later, when the human clicks "approve":
graph.invoke(Command(resume="approve"), config)

Here, we can see that:

• interrupt(...) stops the agent at this line, saves a checkpoint, and sends the details to our app so that we can show them to the human.
• The agent does nothing until a reply comes.
• When the human replies, we call graph.invoke with Command(resume="approve"). Here, graph is our agent, and config tells it which saved conversation to continue.
• The agent loads the checkpoint and runs this step again. This time, interrupt does not stop. It simply returns the human's answer, so decision now holds "approve", and the booking happens.

Note:

• Because the step runs again from its start, we must keep any code that does real work, like booking, after the interrupt line, not before it.
• For this to work, the agent must be set up with a checkpointer, which is the part that saves checkpoints to memory or a database.

To learn Tool use in Agents, Memory in Agents, Agent Architecture, and LangGraph, and to build an AI Coding Agent from scratch, check out our AI and Machine Learning Program at Outcome School.

A simple code example

Let's see the idea in a very small Python example. This is written just for the sake of understanding, so it keeps everything in one simple program.

RISKY_TOOLS = {"book_flight", "send_email", "delete_file"}

def run_tool_with_approval(tool_name, args):
    if tool_name not in RISKY_TOOLS:
        return run_tool(tool_name, args)   # safe tool, run directly

    print(f"Agent wants to call {tool_name} with {args}")
    choice = input("approve / edit / reject: ")

    if choice == "approve":
        return run_tool(tool_name, args)
    if choice == "edit":
        new_args = ask_human_for_new_args(args)
        return run_tool(tool_name, new_args)
    reason = input("Why reject? ")
    return f"Human rejected this action. Reason: {reason}"

Here, we have:

• RISKY_TOOLS is the list of tools that need a human's approval.
• If the tool is not risky, we run it directly with run_tool, which is our function that runs any tool.
• If the tool is risky, we show the human what the agent wants to do and ask for a choice.
• On "approve", we run the tool as planned.
• On "edit", we call ask_human_for_new_args, which lets the human change the inputs, and then we run the tool with the new inputs.
• On "reject", we do not run the tool. We return the reason as the tool result, so the agent reads it and can try another way.

Note: In a real system, we do not use input(), because it blocks the program. We save a checkpoint, send the request to the human, and resume later, as we learned in the previous section.

Which actions need a human?

If the agent asks for approval on every small step, the human gets tired and starts clicking "approve" without reading. This is called approval fatigue, and it makes the human check useless.

So, we must choose carefully. A simple way is to ask two questions about each action:

• Can it be undone? Reading a file changes nothing, so there is nothing to undo. Sending an email cannot be undone.
• How big is the damage if it goes wrong? Renaming a draft is small. Paying money or deleting customer data is big.

We can group actions like below:

We can also use simple rules, for example, "refunds up to 500 rupees run automatically, refunds above 500 rupees need approval". This keeps the human focused only on the decisions that really matter.

Stay updated: Subscribe to our newsletter to get our latest AI and Machine Learning blogs straight to your inbox.

Common mistakes

Most of the time, we do mistakes while building these agents. Let's see the common ones:

• Showing too little. A request like "Approve action?" is useless. The human must see exactly what will happen: which tool, which inputs, and why.
• Ignoring rejections. When a human rejects, the agent must get the reason, so it does not try the same wrong action again.
• No timeout. If nobody replies, the request must not wait forever. We decide a safe default, like canceling after 24 hours or reminding someone.

Advantages and disadvantages

Advantages:

• Risky actions are checked by a human before they happen.
• The agent asks instead of guessing when something is unclear.
• A person stays responsible for important decisions.
• People trust the system more, so they are willing to use it.
• Human edits and rejections become feedback to improve the agent.

Disadvantages:

• It is slower, because the agent waits for a human.
• It needs a human to be available.
• It needs extra work to build: saving state, approval screens, and timeouts.
• If designed badly, it causes approval fatigue.

So, it is a trade-off between speed and safety. The more risky the action, the more a human check is worth the wait.

Now we must have understood how Human-in-the-Loop agents work.

Frequently Asked Questions

Does a Human-in-the-Loop agent ask for approval on every step?

No. It asks only at the important moments. Safe actions like searching, reading, and summarizing run automatically, and only risky actions, like paying money, sending to customers, or deleting data, go to a human first. Asking on every small step causes approval fatigue, where the human starts clicking "approve" without reading.

What happens when a human rejects an action?

The tool does not run. Instead, the agent receives the human's reason as the tool result, so it can try another way or stop. Passing the reason back matters, because it stops the agent from trying the same wrong action again.

What should happen if nobody replies to an approval request?

The request must not wait forever. We decide a safe default ahead of time, like canceling the action after 24 hours or reminding someone. Because the agent's state is saved as a checkpoint, the program does not need to keep running while it waits.

Why must the real work come after the interrupt line in LangGraph?

Because when the agent resumes, it runs the paused step again from its start. This time, interrupt does not stop and simply returns the human's answer. So, code that does real work, like booking a flight, must sit after the interrupt line, not before it.

That's it for now.

Thanks

Amit Shekhar
Founder @ Outcome School

You can connect with me on:

• X
• LinkedIn
• GitHub

Follow Outcome School on:

• X
• YouTube
• LinkedIn
• GitHub

Read all of our high-quality blogs here.