Human-in-the-Loop: Adding Approvals to AI Agent Workflows

Where a human is needed and where not

Human-in-the-loop (HITL) means an AI agent prepares an action, but the action only runs after a person approves it. Approving everything defeats the purpose of automation. You need approval where a mistake is expensive or cannot be undone.

A simple rule: the agent reads, searches, calculates and drafts on its own. A human approves anything that changes the world outside the system: money, messages to customers, deletions and bulk data changes.

How to classify agent actions

List every tool the agent can call and rate each one with three questions:

• Is it reversible? A draft email is; a sent email is not.
• What does a mistake cost? Money, reputation, legal consequences.
• Who sees the result? An internal user, or a customer, partner or regulator.

The answers give you three tiers:

Important: restrictions are enforced in code and access rights, not with a sentence in the prompt. If the agent does not need a delete method, do not give it an API key that can delete.

Designing the approval queue

The queue is a table of requests, and each record holds everything needed to decide in a few seconds:

• what exactly the agent wants to do (tool and parameters, in readable form);
• why: the original request, the context, a short justification from the model;
• what it affects: customer, order, amount;
• buttons for Approve, Reject and Edit and approve.

Show requests where people already work: the CRM, a Telegram bot for staff, an internal admin panel. Notification arrives, someone taps a button, the agent continues.

Technically, the agent run must be able to pause. The agent saves its state, creates the request and ends the step. When a decision comes in, the run resumes from the same point. Many agent frameworks support such interrupts out of the box, but you can also build it yourself with a database and a task queue.

The audit log

Every agent action, automatic or approved, goes into a log:

• time, and the user or process the agent acts for;
• the tool called and its parameters;
• the result or error;
• for approved actions: who approved, when, and what was edited.

Make the log append-only: the agent cannot edit or delete entries. The log is not just for incident reviews. Rejected requests show you where the model gets things wrong most often.

How not to slow everything down

Approvals quickly become a bottleneck when there are too many. What helps:

• Thresholds. Refunds below a set amount run automatically, larger ones go to a person. The business sets the threshold, not the model.
• Batch approval. Twenty similar emails can be reviewed as a list and approved together.
• Timeouts and escalation. If nobody handles a request in time, it goes to another person or is cancelled, but it is never executed silently.
• Gradually extending trust. If a type of action has been approved without edits for a long time, move it to automatic mode with spot checks.
• Clear cards. The better a request is presented, the faster the decision. Raw JSON instead of a description is a common cause of delays.

Common mistakes

• Protection only through the prompt: "never send emails without approval". The model can ignore it.
• Blind approval: the person sees "Send email?" but not the text or the recipient.
• No re-check after approval: parameters may be stale by the time the request is approved. Before executing, check that the order still exists and the amount has not changed.
• One shared key for all tools instead of minimal permissions.