What is human in the loop AI?

Human in the loop (HITL) AI means a person takes part in an AI system’s decisions at chosen points. The AI does most of the work, and a human reviews, approves or corrects it before anything important happens.

For AI agents that can send e-mails, update records or move money, this is one of the most practical safety controls. This page covers when to require approval, who should approve, how to handle timeouts and how to keep a record.

What does human in the loop mean for AI agents?

An AI agent is a language model that can use tools: it reads data, decides what to do and then acts. Without a human in the loop, it acts as soon as it decides. With one, it pauses at certain steps and waits for a person to say yes or no.

Standards bodies and protocols recommend this. The Model Context Protocol specification says there should always be a human in the loop with the ability to deny tool invocations, and that clients should ask for confirmation on sensitive operations. The EU AI Act, Article 14 requires high-risk AI systems to be designed so people can oversee them, override them and stop them.

There are three common levels of involvement:

Level	How it works	Good for
Human in the loop	The agent pauses; a person must approve each chosen action	Sends, payments, deletes, access changes
Human on the loop	The agent acts; a person monitors and can stop it	High-volume, low-risk, reversible work
Human out of the loop	The agent acts with no review	Read-only lookups and drafts nobody else sees

When should an AI agent require human approval?

The best rule is to match approval to the cost of a mistake. A useful way to sort actions:

• Reads (search a folder, look up an order): usually no approval. The risk is about what the person can see, which permissions handle better.
• Writes (create a ticket, update a CRM field, draft and send an e-mail): often ask once per conversation, or ask every time when the change is visible to customers.
• Destructive or irreversible actions (delete a file, cancel a subscription, issue a refund, change access): always ask.

Some actions only need approval above a threshold. A refund agent might act alone below a set amount and ask a manager above it. Conditional rules like this keep approvals rare enough that reviewers take them seriously.

Other signals that call for approval:

• The action affects someone outside the company.
• The agent is new, or its instructions just changed.
• The request came from an untrusted channel, such as a public website chat.
• The data involved is regulated or confidential.

Who should approve an AI agent’s actions?

There are three common patterns, each with trade-offs.

1. The person in the conversation. Fast and natural: the agent shows what it wants to do and the asker clicks approve. Best for actions on the asker’s own work.
2. An admin or owner. Useful when the asker should not decide alone, for example on changes to shared systems.
3. A named approver, often by e-mail or chat. Best for money, access and sensitive records. For separation of duties, the asker should not be able to approve their own request.

Whoever approves needs enough information to decide: what the agent wants to do, with which inputs, and why. An approval that only says “Agent wants to run a tool” is a rubber stamp waiting to happen.

What happens when an approval times out?

Approvals must not wait forever. A request that sits for days may no longer make sense, and a pending action can surprise people when it finally runs.

Good practice:

• Set an expiry time, such as an hour, and let teams adjust it per case.
• Treat an expired request as a refusal. Nothing should run by default.
• Let the agent explain to the person that the action did not happen and why.
• Make sure a refusal grants nothing, so the agent cannot find another path to the same action.

How do you audit human in the loop decisions?

An approval only has value if you can check it later. Record, for each request:

• What the agent asked to do, and the inputs.
• Who asked, who decided and when.
• The decision (approved, refused or expired).
• What actually ran as a result.

Review the log from time to time. If one reviewer approves hundreds of requests in a few minutes, the control is not working. If an action is never refused, it may not need approval at all. The NIST AI Risk Management Framework treats this kind of ongoing monitoring as part of managing AI risk.

What are the limits of human in the loop?

• Approval fatigue. Too many requests train people to click yes without reading.
• Automation bias. People tend to trust a confident system, even when it is wrong.
• Speed. Waiting for a person slows the work, which is why reads usually skip approval.
• It does not replace other controls. Approvals decide whether one action runs. They do not decide what data the agent can see; that is the job of permissions and guardrails.

How promptev handles human in the loop

• Each tool on an agent has an approval setting: Inherit, None, Ask once (the first call in a conversation) or Always ask. By default reads need none, writes ask once and destructive actions always ask, and a refusal grants nothing.
• Registered HTTP, database and MCP tools can be set to Not needed, Ask every time or “Ask if” a condition, such as an amount over 1,000. An admin’s rule is a floor agents cannot weaken.
• Approvals can be decided inline by the person in the conversation or a workspace admin or owner, on Slack by the asker only, or by e-mail by a named approver (the asker can never decide an e-mailed request).
• Requests appear on the Approvals page and as cards in the App, as e-mail links, as Slack buttons, and inside MCP clients that can show them. They expire after 60 minutes by default, or your own timeout.
• Orchestrations can pause for a reviewer’s sign-off or send work back for changes.
• Every run and approval is recorded in the audit trail with who decided. See governance.