Human in the Loop AI Agents: Fewer, Better Gates

TL;DR: Human in the loop for AI agents means the run stops before a chosen action and waits for a person. The common advice is to gate anything risky, but a 2026 study that treats the reviewer as a finite, fatiguing resource found that realized safety rises and then falls as the escalation rate goes up. More approval requests can make a system less safe. The useful question is not whether to add a human, it is which actions are worth spending a person's attention on, and what your platform does with the run while it waits. This post covers both, and shows the second half as configuration in Heym's human review feature.

Key Takeaways:

• Human review is an execution-control pattern for agents, not the data-labeling loop the term used to describe. Conflating the two leads to designs that collect approvals nobody ever uses
• Reviewers do not agree on what counts as risky. On a hand-labeled set of agent actions, agreement measured at a Fleiss' kappa of 0.52, which is moderate at best
• Safety is not monotonic in oversight. Past a point, adding gates lowers the quality of every decision the same reviewer makes
• The hard part is not pausing, it is everything after: notification, expiry, cost while pending, and whether resume uses the workflow as it was or as it is now
• Repeated tool calls need an approval scope, otherwise the second identical call pauses again and teaches the reviewer to click accept without reading

---

Table of Contents

• What Is Human in the Loop for AI Agents?
• The Two Things People Mean by HITL
• In the Loop, On the Loop, Out of the Loop
• Why More Oversight Is Not More Safety
• Which Actions Actually Deserve a Gate
• What Happens to a Run While It Waits
• Two Kinds of Human Input, One Pause
• Approval Scope: Always, Once, Never
• Human Wait Time Is Not Compute Time
• Building an Approval Gate Without Code
• Mistakes I Keep Seeing
• FAQ
• References

What Is Human in the Loop for AI Agents?

Definition: Human in the loop for AI agents is an execution-control pattern in which an agent stops before a designated action, hands a decision to a person, and does not continue until that person accepts, edits, or refuses it. The run enters a pending state at the pause and resumes from that point once a decision arrives.

Three things in that definition do the work.

It is execution control, so the unit of analysis is an action, not an output. You are not reviewing what the agent said, you are deciding whether it may do the thing it proposed.

It is blocking, so the run genuinely stops. A notification that an agent did something, sent after the fact, is monitoring. Useful, but a different pattern with different guarantees.

It is resumable, so the work done before the pause is not thrown away. If your agent has to start over after every approval, you have a retry loop with extra steps.

If you are new to the surrounding concepts, agentic AI covers what makes an agent an agent, and agentic workflows covers how these runs get structured in the first place.

What is Heym? Heym is an open source, self-hosted AI workflow automation platform with a visual canvas. Workflows are built from nodes such as AI Agent, LLM, RAG, HTTP, and Condition, and run on your own infrastructure, so credentials, drafts awaiting approval, and the decisions reviewers make on them never leave your environment.

The Two Things People Mean by HITL

Search for human in the loop and you will get two incompatible answers presented as one topic. This is the single most confusing thing about the term, and almost nobody separates them.

The older meaning comes from machine learning operations. A model produces a prediction, a person corrects it, the correction becomes training data, the model gets better. Wikipedia's entry and most enterprise explainers still describe this cycle, and it is a real and valuable pattern.

The newer meaning is the one this post is about. An agent proposes an action, a person approves it, the action happens or does not. No model is updated. No training data is produced. The approval is a gate, not a label.

	HITL as data labeling	HITL as action gating
What the human touches	A prediction or a label	A proposed action
When it happens	Mostly during training and evaluation	At runtime, mid-execution
Effect on the model	Feeds fine-tuning or evaluation sets	None
What blocks	Nothing, the system keeps serving	The run itself
Failure if you skip it	The model stops improving	The action happens unreviewed
Right metric	Label quality, inter-rater agreement	Time to decision, reviewer load
Typical owner	Data or ML team	Whoever owns the workflow

The reason this matters practically: if you carry the labeling frame into an agent design, you build the wrong thing. You start logging every approval as though it will train something, you measure reviewer agreement instead of reviewer throughput, and you gate broadly because in labeling more human input is straightforwardly better. In action gating it is not, for reasons the research below makes concrete.

In the Loop, On the Loop, Out of the Loop

The second confusion is the posture. These three get used interchangeably and describe very different arrangements.

Definition: Human on the loop means a person supervises an agent that runs autonomously inside limits set in advance, intervening only when something crosses a line, rather than approving each action before it happens. The difference from human in the loop is whether the run can complete without a decision: on the loop it can, in the loop it cannot.

Posture	Where the person sits	Run continues without them?	Best for	Main risk
In the loop	Inside the execution path	No	Irreversible, rare, high-cost actions	The person becomes the bottleneck, then the rubber stamp
On the loop	Alongside, monitoring	Yes, within preset limits	High-volume, reversible work	Limits were wrong and nobody was watching closely
Out of the loop	Not involved during the run	Yes	Work whose failure mode is cheap and visible	Nobody finds out until a customer does

The mistake is picking one posture for a whole system. Posture is a property of an action, not of a team or a product.

The same customer support workflow can be out of the loop for looking up an order, on the loop for drafting a routine reply, and in the loop for issuing a refund above a threshold. That mixed arrangement is what most working systems converge on, and it is worth designing deliberately rather than arriving at by accident.

Why More Oversight Is Not More Safety

Here is the finding that reframes this whole topic, and that I have not seen cited on a single page currently ranking for it.

A June 2026 paper, Oversight Has a Capacity, takes the standard approval-gate pattern and questions two assumptions almost every guide makes: that there is a ground truth about which actions are risky, and that the reviewer is a perfect, always-available oracle.

On the first assumption, the authors hand-labeled 125 adversarially weighted agent actions and measured how much reviewers agreed on which ones were risky. Agreement came out at a Fleiss' kappa of 0.52, which is moderate. There is no single correct label for risky, which means a guard tuned to somebody's idea of risky is tuned to an opinion.

The second assumption is the interesting one. When they model the reviewer as endogenous, meaning the reviewer fatigues as the escalation load grows, realized safety becomes an inverted U in the escalation rate.

Key principle: Escalating more actions raises safety only until reviewer fatigue costs more than the extra review buys. Past that point, additional gates make the system less safe, because they degrade the quality of every decision the same person is making. The safety-optimal policy escalates less than everything.

The paper also describes a flooding attack that follows directly: an adversary generates enough low-stakes approval requests to exhaust the reviewer, then slips a malicious action through a person who has stopped reading. Anyone who has approved forty dependency bumps in a row knows exactly how that ends.

It is the same shape as the alert fatigue problem that security operations teams have been losing to for a decade, arriving now in agent tooling. The authors are careful to note that the inverted U and the flooding attack are modeling results that motivate a human study rather than measured human outcomes, and their code is public.

A peer-reviewed paper in AI and Ethics from May 2026, Designing meaningful human oversight in AI, arrives at the same place from the governance side. It names two ways oversight fails: humans act as rubber stamps, approving outputs they do not fully understand, or systems get constrained so tightly that the AI collapses into rule-following automation and loses the qualities that made it useful.

The paper's fix is to separate operative agency, the system's capacity to generate solutions, from evaluative agency, the person's capacity to judge and if necessary override them. A gate that a person cannot meaningfully evaluate is not oversight. It is a click.

Both papers point the same direction. Approval capacity is a budget. Every gate you add spends from it, and the spending is not free even when nobody clicks refuse.

Which Actions Actually Deserve a Gate

So spend the budget deliberately. Here are the four questions I use, in order. An action needs a human gate if the answer to any of them is yes.

1. Is it hard to reverse? A sent email, a published post, a transferred payment, a deleted record, a merged branch on main. Reversibility is the strongest single signal, because a reversible mistake costs a correction while an irreversible one costs an incident.

2. Is it visible outside your team? Anything a customer, a regulator, or the public sees. The cost here is reputational and does not show up in your error rate.

3. Would a person actually know better? This is the question that gets skipped, and it is the one the AI and Ethics paper is really about. If the reviewer has no context the agent lacks, no policy in their head that is not in the prompt, and no way to verify the claim in front of them, the gate produces a click and a false sense of control. Move the effort into the prompt or into a deterministic check instead.

4. Would you notice if it were wrong? If a mistake surfaces loudly within minutes, monitoring beats gating. If it surfaces silently in three weeks, gate it.

Where the gate goes: put the approval immediately before the tool call that performs the action, not before the agent's plan and not after the action has run. Gating the plan controls nothing, because the agent can still choose a different action on the way. Gating after execution is a notification, not an approval. The one exception is when the risky part only becomes knowable partway through, in which case let the run gather context first and place the gate at that step instead.

Everything that answers no to all four runs unattended. That is not carelessness, it is what keeps the reviewer sharp for the actions in the first list. For the classes of failure that are better handled by a deterministic check than by a person, LLM guardrails covers the alternatives, and prompt injection covers why an agent reading untrusted content is a separate problem that approval alone does not solve.

Trigger

Workflow starts

Cron, webhook, portal message, or a manual run. No human involved yet.

Agent

Agent works and proposes

It reads, calls tools, drafts. All of this is unattended by design.

Gate

Agent calls request_human_review

It reaches an action its guidelines say needs a person, and hands over a Markdown review.

Notify

Review branch fires immediately

Slack, email, or audit log gets the review URL while the main branch is still waiting.

Pending

Run holds at a snapshot

Execution status becomes pending. Nothing is burning while nobody is looking.

Decide

Reviewer accepts, edits, or refuses

A one-time public link. The token locks after the decision.

Outcome

Accepted or edited

The run resumes from the stored snapshot and the agent continues with the approved text.

Refused

The run resumes carrying a refused decision, and downstream branches handle it explicitly.

Nobody answers

The link expires after 168 hours and the request can no longer be used.

What Happens to a Run While It Waits

Every guide on this topic explains how to pause. Almost none explain what you are left holding while the run is paused, which is where the operational pain actually lives. These are the questions to ask about any platform, including this one.

Question	Why it bites you	How Heym answers it
Does the pause hold a process or a snapshot?	A held connection dies with a deploy or a restart	A stored execution snapshot
Does it cost anything while pending?	Some designs keep a model session warm	No, a pending run is not executing
How does the reviewer find out?	A pause nobody hears about is an abandoned run	A separate review output branch fires at the moment of the pause
What if nobody answers?	Pending runs pile up forever	The link expires after 168 hours and returns a gone response
Can the link be reused?	A shared approval link is an authorization hole	The token locks once a decision is submitted
Does resume use the old workflow or the new one?	Editing mid-pause can silently change what you approved	Resume uses the snapshot as it was, not the latest edit
Can it pause more than once per run?	One gate per run is not enough for real work	Multiple sequential checkpoints, a new one-time link each time

That fourth row is worth dwelling on. Review links in Heym expire after 168 hours, which is seven days, and an expired link returns a gone response rather than quietly accepting a stale decision. Seven days sounds generous until you send a review request on a Friday afternoon before a week of vacation.

The sixth row is the one that surprises people. If you pause a run, then edit the workflow, then approve, the resume replays the workflow you paused, not the one you just edited. That is the safer default, because the alternative is approving one thing and executing another. It also means a fix you make during a pause does not reach the run you are trying to fix.

Two Kinds of Human Input, One Pause

Approval is not the only reason a run should stop and wait for a person. Sometimes the agent does not need permission, it needs an answer.

This is easy to miss because both look identical from the outside. The run is pending, somebody has a link, and nothing moves until they act. Underneath they are different questions. One asks may I, the other asks which one.

Heym ships both, on two different nodes, riding the same pause machinery.

	Agent node review	Codex node follow-up
What the human is asked	May I do this?	Which one did you mean?
Triggered by	The agent calling request_human_review	The coding agent hitting an ambiguity it cannot resolve
The human sees	A Markdown draft of the proposed action	A specific question and an answer box
Available responses	Accept, Edit and continue, Refuse	A written answer
Public link	/review/{token}	/codex/followup/{token}
Link lifetime	168 hours	168 hours
What the run gets back	A decision plus possibly edited text	The answer text, as context
Configured by	hitlEnabled and hitlSummary	Nothing, it is inherent to the node

What the two share

The overlap is the part you would otherwise have to build twice. Both persist the execution as a snapshot rather than holding a process. Both mint a one-time public link with the same seven-day expiry. Both resume from the stored snapshot, and both show up in the execution timeline as a wait span separate from compute.

Both also fire the same notification branch. The Slack or email node you wired for approvals delivers a Codex question too, with no extra work.

Why that matters outside this product

Pausing for a human is not a feature of your approval system. It is a capability of your execution engine.

Once a run can stop, persist, notify, expire, and resume, then "wait for an approval" and "wait for an answer" are the same machinery carrying different payloads. Build the pause only inside your approval logic and you get to write all of it again the first time an agent needs to ask a question rather than ask permission.

One honest limit: this is not universal across every node. The OpenCode node runs to completion without a resume path in the current version, so an ambiguity there ends the run rather than pausing it.

Key principle: Design the pause at the execution layer, not inside the approval feature. Approval and clarification are the same interruption wearing different questions.

Approval Scope: Always, Once, Never

Now back to the fatigue problem, because this is where a platform can either help or actively make it worse.

An agent that calls the same tool twelve times in a run, and pauses for approval on each one, produces twelve approval requests that all look identical. By the fourth, the reviewer has stopped reading. That is the flooding attack from the paper above, except nobody had to attack you, you built it yourself.

The fix is to give repeated calls a scope. In Heym, the written approval guidelines are interpreted into one of three modes per tool:

Scope	Triggered by wording like	Behavior on the second identical call
always	always, on each, for each	Pauses again
once	once, only one time	Already approved, continues without pausing
never	never, do not ask, already approved	Never pauses for that tool

There is a subtler case underneath, and it is the one I spent the most time on when I implemented the single-review policy for this feature. "Ask only once and then never ask again" and "ask once per tool" look like the same sentence to a quick reading, and they mean completely different things.

The first is a cap on the entire run, so after one approval the agent should stop asking about anything. The second is a per-tool scope, so a different tool still gets its own approval. Heym now separates them explicitly: wording like "once per" or "for each" is read as the per-tool scope, while "only once" or "never ask again" caps the whole run, and later review requests come back already satisfied instead of pausing.

The general rule is worth stating independently of any product.

Notable fact: An approval request that a reviewer has already seen in the same run is not additional safety. It is a test of their patience, and the paper above suggests they will fail it in a predictable direction.

Human Wait Time Is Not Compute Time

One more operational detail nobody writes about, and it will quietly corrupt your metrics.

When a run pauses for a person, the wall clock keeps going. If your execution timeline records only the total, then a workflow that took nine seconds of compute and eleven hours of waiting shows up as an eleven hour run. Your p95 latency now measures how quickly your colleagues check Slack. Compare two workflows on that number and you learn nothing.

Heym materializes the wait as its own span. The compute before the pause is kept as a pre_review phase with its real duration, and the gap between pause and resume becomes a separate hitl_wait span in the execution timeline.

While the run is still pending, the interface synthesizes a live wait span, so you can see the clock running on a decision nobody has made yet. The two numbers stay separable: machine time on one side, human time on the other.

This matters more than it sounds. Human time is the number you optimize by changing who reviews and how they are notified. Machine time is the number you optimize by changing models, prompts, or tools. Averaging them together hides both. If you are already instrumenting agent runs, AI agent observability covers the wider picture, and the same separation logic applies to any long external wait, not only human review.

Building an Approval Gate Without Code

Every implementation guide currently ranking for this topic is code. LangGraph interrupts, Temporal signals, Spring AI checkpoints, Cloudflare's agents documentation, Temporal's cookbook, the OpenAI Agents SDK guide. They are good documents. They also assume you are writing and deploying an application.

In Heym the same pattern is node configuration. Here is the whole thing.

Enable review on the agent

In the Agent node properties, turn on hitlEnabled. Two things appear: a request_human_review tool the agent can call, and a second output handle on the canvas labeled review. Keep JSON output off on that agent, since human review works on text output in the current version.

Write the guidelines

hitlSummary takes plain language, not a schema. "Always ask before sending anything to a customer. Never ask before reading internal documents." The agent reads these along with its system prompt to decide when to call the review tool, and for MCP tools the wording is what determines the scope from the table above.

Wire the notification

Connect a Slack or email node to the review handle. That branch runs at the moment of the pause, not after the decision, and it receives the pending payload: summary, draftText, reviewUrl, and a shareMarkdown block that is already formatted to post. This is the part that decides whether your approval workflow works in practice, because a review nobody knows about is just a stalled run.

Handle the decision downstream

The reviewer opens a public /review/{token} page, with no login, and chooses accept, edit and continue, or refuse. Downstream nodes read $agentLabel.decision to branch on accepted, edited, or refused. Give refused its own path. A refusal that falls through to the same branch as an approval is a bug that only shows up on the day it matters.

For a complete worked example, the HITL Support Reply Agent template drafts a customer reply, posts the pending review URL to Slack, and waits. The AI customer support agent walkthrough uses it as one step of a larger build, and the agentic Kanban board shows the same pause surfacing as an amber card when a board chain hits a review. Full behavior and current limits are in the human review documentation.

Two limits worth knowing before you design around it. Approval review is configured on Agent nodes, so the Codex follow-up described above is a sibling mechanism rather than the same setting on another node. And nested sub-workflows cannot enter a pending state in the current version, so request the review from the parent agent before calling into one.

Mistakes I Keep Seeing

Gating the plan instead of the action. Approving an agent's stated intention feels productive and controls nothing, because the agent can still do something else on the way. Gate the tool call.

A gate with no context. "The agent wants to send an email. Approve?" is a question nobody can answer correctly. Put the actual text, the recipient, and the reason in the request. The reviewer's job is judgment, and judgment needs material.

Treating refusal as an error. A refused review is a successful outcome of a working control. If your workflow logs it as a failure, your error rate now punishes the feature for doing its job.

One gate for everything. Different actions need different reviewers. A refund is a support lead's call and a schema change is not. If everything routes to the same person, you have built a queue, not an approval system.

Forgetting the run is still there. Every pending run is an obligation. Somebody has to own the pending queue, or your first HITL workflow will still have three runs waiting in it next quarter.

If you are assembling the rest of the agent around this, how to build an AI agent covers the pieces, and multi-agent AI systems covers what changes when the thing asking for approval is one of several agents.

FAQ

What is human in the loop for AI agents? Human in the loop for AI agents means the agent stops before a specific action, hands a decision to a person, and waits for an answer before continuing. It is an execution-control pattern, not a training technique. The agent proposes a refund, a deploy, or an outbound email, the run enters a pending state, a reviewer accepts, edits, or refuses it, and the run resumes from where it stopped. Nothing about the model changes as a result of the approval.

What is the difference between human in the loop and human on the loop? In the loop means the person sits inside the execution path and the run cannot continue without a decision. On the loop means the agent runs to completion on its own inside limits you set in advance, while a person monitors and intervenes only when something looks wrong. In the loop trades throughput for control on a per-action basis. On the loop trades per-action control for throughput and relies on the limits and the monitoring being good. Most production systems use both, on different actions in the same workflow.

How do you prevent approval fatigue in human-in-the-loop workflows? Gate fewer actions and make each gate carry more information. A 2026 arXiv study that modeled the reviewer as someone who fatigues found that realized safety follows an inverted U as the escalation rate rises, so past a point more approval requests make the system less safe rather than more. Practical measures: gate only irreversible or externally visible actions, give repeated tool calls an approval scope so the second identical call does not pause again, and put the decision context in the request instead of making the reviewer go find it.

What happens to an agent run while it waits for approval? That depends on the platform, and it is worth checking before you rely on one. The questions that matter are whether the paused run holds an open connection or a stored snapshot, whether it costs anything while pending, how the reviewer finds out there is something to review, what happens if nobody ever answers, and whether resuming uses the workflow as it was when it paused or as it is now. In Heym a paused run stores a snapshot, costs nothing while pending, notifies through a separate canvas branch that fires immediately, expires the review link after 168 hours, and resumes from the stored snapshot rather than the latest edit.

Can a reviewer approve an agent action from Slack or email? Yes, if the platform gives you a notification path that runs at the moment of the pause. In Heym, enabling human review on an agent adds a second output handle on the canvas called review. Anything wired to that handle runs immediately with the pending payload, which includes the review URL and a ready-to-post Markdown block, so a Slack node or an email node on that branch delivers the link while the main branch waits. The decision itself happens on a public review page rather than inside the chat message.

Is human in the loop the same as human oversight? No. Human oversight is the goal of keeping an identifiable person accountable for what a system does. Human in the loop is one mechanism for reaching it, and not always the best one. A peer-reviewed 2026 paper in AI and Ethics describes two ways oversight fails in practice: people become rubber stamps who approve outputs they do not understand, or the system is constrained so tightly that it collapses into rule-following automation. Both of those can happen in a system with a human in the loop on every action.

Where This Leaves You

The instinct to put a person in front of everything an agent does is a good instinct applied without a budget. Attention is finite, it degrades under load, and a reviewer who has approved eleven things without reading them is not oversight in any sense that would survive an incident review.

So gate less, and gate better. Pick the actions that are irreversible, externally visible, genuinely benefit from what a person knows, or would fail silently. Give the reviewer enough context to make a real decision. Give repeated calls a scope so the same question does not get asked twice. And before you rely on any of it, find out what your platform does with a run that has been waiting since Friday.

That last part is why I wrote this. The pause is the easy half.

References

• Turan, E. et al. (2026). Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human. arXiv:2606.08919
• Designing meaningful human oversight in AI (2026). AI and Ethics, Springer
• What is Human-in-the-Loop? Stanford HAI AI Definitions
• What Is Human In The Loop (HITL)? IBM Think
• Human in the Loop Cloudflare Agents documentation
• Human-in-the-Loop AI Agent Temporal Platform documentation
• Human-in-the-loop OpenAI Agents SDK guide
• Human-in-the-loop Wikipedia

Steps at a glance

1. Decide which actions get a gate. Before touching the canvas, list the actions in the workflow and keep a gate only where the action is hard to reverse, visible outside your team, expensive to get wrong, or where a person genuinely knows something the agent cannot see. Everything else runs unattended. This list is the design, and the platform work is the easy part.
2. Turn on human review for the agent. Open the Agent node properties and enable hitlEnabled. This adds a request_human_review tool to the agent and a second output handle on the canvas labeled review. Keep JSON output off on that agent, since human review works on text output in the current version.
3. Write the approval guidelines the agent will follow. Fill in hitlSummary with plain-language rules for when to ask, such as always ask before sending anything to a customer, never ask before reading internal documents. For MCP tools the wording is interpreted into an approval scope: phrases like on each map to always, phrases like only one time map to once, and phrases like do not ask map to never.
4. Wire the review branch to a notification. Connect a Slack, email, or logging node to the review output handle. That branch runs at the moment the run pauses and receives the pending payload including summary, draftText, reviewUrl, and a ready-to-post shareMarkdown block, so the reviewer gets a link instead of discovering the pause later.
5. Branch on the decision downstream. After the agent, use a Condition node on $agentLabel.decision to separate accepted, edited, and refused outcomes. Refused should do something specific such as logging an internal note, not silently fall through to the same path as accepted.
6. Run it once and read the timeline. Trigger the workflow, approve from the review page, then open the execution timeline. The pause appears as its own hitl_wait span next to the agent's compute span, so you can see how much of the run was machine time and how much was a person being asleep.