The fastest way to lose trust in an agent is to let it do something irreversible that it got wrong. The fix is not to supervise everything, which would defeat the point of automating, but to design the agent so a human stays in control of exactly the moments that matter. That design is human-in-the-loop: the agent runs freely on the safe steps and pauses for a person on the risky ones. Getting the placement right is the difference between oversight that protects you and oversight that drowns you.

This guide covers both halves of the job. The design half: where to place approval gates, how to use confidence thresholds, how to build escalation, and how to keep oversight from turning an autonomous agent back into a manual chore. And the mechanics of a single approval step: what the approver needs to see, what happens when nobody answers, what to record every time, and when an action has earned its way out of approval for good.

What human-in-the-loop is

Human-in-the-loop means a person reviews or approves certain agent actions, while the agent does everything else on its own. It is not the same as a human doing the work with AI assistance, and it is not full autonomy either. It is a middle setting: the agent is trusted with the bulk of the task and a human is kept in control of the decisions that carry real consequences. The pattern exists because most useful work is a mix of low-stakes steps, where speed matters, and a few high-stakes ones, where a mistake is expensive.

The point of the pattern is to spend human attention where it counts. Reviewing every action is just doing the job manually with extra steps. Reviewing nothing means a confidently wrong agent can do real damage. Human-in-the-loop sits between those failures by spending oversight only where it changes the outcome, which is also why it pairs naturally with the bounds in AI agent guardrails and safety.

Where to place a gate

An approval gate is a point where the agent stops and waits for a human yes before continuing. The rule for placing one is reversibility. If an action is easy to undo, let the agent do it and fix mistakes after the fact. If an action is irreversible or expensive, sending money, emailing a customer, deleting records, publishing something public, put a gate in front of it. The cost of a wrong reversible action is a quick correction; the cost of a wrong irreversible one can be permanent. OWASP's guidance on excessive agency in LLM applications puts it the same way: use human-in-the-loop control to require a human to approve high-impact actions before they are taken.

Gate the action, not the thinking

A common mistake is gating the agent's reasoning instead of its actions. You do not need to approve the agent's plan to draft a reminder; you need to approve the actual send. Let the agent think, research, and prepare freely, and place the gate at the boundary where it touches the real world. This keeps the agent fast where speed is harmless and careful where care is needed, and it limits how far a single bad decision can travel, the idea behind how to limit agent actions.

Confidence thresholds

Gating every instance of a risky action still scales poorly when there are thousands of them. A confidence threshold makes the gate smarter: route work by how sure the agent is. When the agent is highly confident, above the threshold, it proceeds on its own; when it is uncertain, below the threshold, it sends the action to a human. Now review is concentrated on the genuinely doubtful cases, and the clear ones flow through automatically.

Setting the threshold honestly

The threshold is a dial between safety and throughput, and where you set it depends on the cost of a mistake. A refund agent handling small amounts can run a low threshold and auto-approve most cases; one handling large sums should set it high so more goes to a human. The honest caveat is that a model's stated confidence is not always reliable, so pair the threshold with hard rules for the highest-stakes actions rather than trusting confidence alone. How to judge whether the agent's confidence is meaningful connects to AI agent evaluation metrics.

Designing escalation

Approval handles the actions you expected to be risky. Escalation handles the situations you did not expect: the agent hits something ambiguous, a tool fails repeatedly, or a result does not make sense. A well-designed agent does not guess its way through these; it stops and hands the situation to a person. Escalation is the safety net under the whole system, and it is what separates an agent that fails safely from one that fails silently.

Make escalation specific

Vague escalation is no escalation. Define the triggers, repeated tool failure, low confidence on a high-stakes action, a contradiction in the data, and define who receives the escalation and what they see. The handoff to the human should carry enough context that the person can decide quickly without reconstructing the whole run. An agent that escalates clearly is exercising good judgement about its own limits, which is closely tied to how it recovers in AI agent error handling and rollback, and to knowing how to halt cleanly in how to stop an agent mid-task.

What the approver needs to see

Mechanically, an approval gate is a wrapper around one high-risk action. The agent proposes the action and its arguments, the wrapper checks them against your allow-lists and policy, puts the request in an approval queue with its context, and waits. Approved, it executes. Rejected, it aborts and tells the agent why. No answer, it follows the timeout rule in the next section. The agent sees the decision as the result of a tool call; it never runs the approval logic itself, which is what keeps the approval auditable separately from the agent's reasoning.

The weak point is the request the human actually reads. Approvers without context fall into one of two habits: approving everything, or rejecting on principle. Both are dangerous. Five pieces of information keep them in the useful middle:

  1. Who is asking. Which agent, and which version of its instructions produced this request.
  2. The goal. What the user asked for, and what the agent has established so far.
  3. The exact action. The real payload that will go out if approved, not a summary of it.
  4. The alternatives. What else the agent considered, and why it chose this.
  5. The cost of being wrong. What undoing this would take, if it can be undone at all.

The fifth is the one most often left out and the one that changes behaviour most. An approver who reads "this email cannot be unsent; if it is wrong, the fix is a follow-up apology" reads the email body more carefully than one who sees the body alone.

When nobody approves: the timeout

Every gate needs an answer for silence. Set the timeout to match how long the action stays useful, because an approval that arrives after the moment has passed is worthless either way. Some starting points:

ActionHow long it stays usefulSuggested timeout
Reply to a customer emailAbout a day before it goes stale24 hours
Book a meeting slotA few hours before the slot is gone2 to 4 hours
Pay a supplier invoiceSeveral business days5 business days
Triage an internal chat messageMinutes30 minutes

What happens at the timeout matters more than its length. The agent must not act on its own because nobody objected; auto-acting on timeout is the most common shortcut in approval systems and a reliable source of incidents. Instead:

  1. Log the timeout with its full context.
  2. Escalate to a fallback approver: a manager, or a shared queue.
  3. Note it against the original approver's queue, so chronic timeouts become visible.
  4. If the fallback also times out, drop the action. Do not execute it.

The one exception is an action that has already graduated out of approval (more on that below) where the gate is kept only for visibility. Even then, record an auto-executed action differently from an approved one, so the audit can tell them apart.

Oversight without the drag

The failure mode of human-in-the-loop is over-gating. Add a checkpoint to every step out of caution and you rebuild the manual process you were trying to escape, except slower because now a human is waiting on an agent. The whole value of an agent is that it runs the routine parts without you; gating those parts throws that value away. Discipline here means resisting the urge to approve everything just because you can.

The way to keep oversight light is to be ruthless about what actually needs it. Most steps in most tasks are reversible and low-stakes, and those should never reach a human. Reserve gates for the irreversible, thresholds for the uncertain, and escalation for the unexpected. When oversight is concentrated on the few moments that matter, the agent stays fast and you stay in control, which is the trust model worth aiming for, explored in AI agent trust models.

Approval fatigue, and three rules that contain it

Over-gating has a predictable spiral. Approvers see more requests than they can read; the quality of review drops; a bad action gets waved through; an incident follows; the team adds more approvals; the queue gets louder still. Three rules break it:

The dashboards that tell you when an action is ready to graduate are covered in how to monitor agent activity.

What to record for every approval

An approval you cannot look up later is governance in name only. Every approval event should write one row with these fields:

  1. The timestamp, with time zone.
  2. Who decided: the approver's ID, role or queue.
  3. Which agent asked, with the version of its instructions and the model it ran on.
  4. The action type, such as "send email" or "post payment".
  5. The full action arguments, exactly as submitted.
  6. The decision: approve, reject, timeout or escalate.
  7. The approver's reason, if they gave one.
  8. A link to the executed action's own record.

Keep the trail append-only, make it searchable by approver, action type and date, and retain it as long as the record behind the action has to be kept. For anything that touches money or health data, that is a question of years, so check the rule that applies to you.

Graduating actions out of approval

Approval gates are scaffolding. Decide up front what an action has to show before its gate comes off, and write the bar down so it is not argued case by case:

When the bar is met, remove the gate and let the action run under its other guardrails. If an incident follows, put the gate back immediately and work out what the record missed. The thinking behind those levels of trust is in AI agent trust models.

A rollout pattern for the first month

  1. Week one: approve everything. The queue is loud on purpose. What you are learning is which action types are safe.
  2. Week two: release the quiet ones. Action types approvers almost never reject stop asking. Everything else stays gated.
  3. Weeks three and four: keep going. Continue releasing low-rejection action types, and add batch approval for the high-volume, low-risk ones that remain.
  4. Month two: read the log. Find the actions approvers consistently take a long time to review. Either give that request better context, or downgrade the action so the agent suggests rather than asks to act.
  5. Every quarter: re-check the list. When a policy or product change alters how much harm an action can do, or how hard it is to undo, reassess its gate.

What it means for buyers

If you run agents rather than build them, you do not place gates or tune thresholds, but you should know what the agent does on its own and what it brings to you first. That single question, what runs autonomously and what waits for my approval, tells you most of what you need about how much an agent can be trusted with a given task.

On a marketplace, the builder designs the oversight and you describe the outcome and your risk tolerance. A good agent makes its gates visible: it is clear about which actions it will pause for and which it will handle alone. When you compare agents for anything that touches money or customers, prefer the one that can tell you exactly where the human stays in the loop over one that promises full autonomy with no pause points at all. The broader question of what to hand an agent is in what can an AI agent actually do.

Frequently asked questions

What does human-in-the-loop mean for an AI agent?

Human-in-the-loop means a person reviews or approves certain agent actions before or after they happen. The agent does the work, but a human stays in control of the moments that matter, such as irreversible or high-stakes actions. It is a design pattern for keeping oversight without doing everything by hand.

Where should you put a human approval gate in an agent?

Put a gate before any action that is irreversible, expensive, or hard to undo: sending money, emailing customers, deleting data, signing anything. Let the agent run freely on low-risk, easily reversible steps. The goal is to spend human attention only where a mistake would actually hurt.

What is a confidence threshold in human-in-the-loop design?

A confidence threshold routes work based on how sure the agent is. Above the threshold the agent proceeds on its own; below it, the action is sent to a human. It concentrates review on the uncertain cases and lets the agent handle the clear ones, so oversight scales without reviewing everything.

Does human-in-the-loop slow an agent down?

It can if you gate everything, which defeats the purpose. Good design gates only the risky or uncertain actions, so most of the work still runs at full speed and humans see only what truly needs a decision. Over-gating turns an autonomous agent back into a manual process.

Do buyers configure human-in-the-loop themselves?

On a platform like Gravity, the builder designs where the agent pauses for approval and when it escalates, and you describe the outcome and your risk tolerance. Knowing the pattern helps you ask the right question: what does this agent do on its own, and what does it bring to me first?

How long should an agent wait for a human to approve?

As long as the action stays useful. A customer email reply goes stale in about a day, a meeting slot in a few hours, a supplier payment can wait several business days. When the window closes, the agent should not act on its own: it logs the timeout, escalates to a fallback approver, and drops the action if the fallback does not answer either.

What should an approval request show the approver?

Five things: which agent is asking and which version of its instructions produced the request, what the user asked for, the exact action with its full payload, the alternatives the agent considered, and what undoing the action would take if it turns out wrong. Without them, approvers drift into approving everything or rejecting everything.

How do I prevent approval fatigue?

Approve actions, not whole runs; batch low-risk approvals of the same type into one decision; and graduate actions out of approval once they have a long, clean record. Tired approvers approve everything, so a queue that is too loud produces the incidents it was meant to prevent.

What should be recorded for each approval?

At minimum: the timestamp, who approved, which agent and instruction version asked, the action type, the full action arguments, the decision (approve, reject, timeout or escalate), any reason the approver gave, and a link to the action that was executed. Store it append-only so it can be searched by approver, action type and date, and keep it as long as the underlying record has to be kept.

Three takeaways before you close this tab

Sources