Human-in-the-loop approvals for AI agents

“Can a human approve before the agent acts?” is the question that decides whether an agent is allowed into production with a client. This guide covers what a defensible approval gate actually requires, why a confirm dialog is not one, and a working pattern you can run locally.

What does a real approval gate need?

Four properties separate a gate a reviewer will accept from a speed bump:

• A closed set of actions. Only action types registered in code can execute at all. The model can propose anything; proposing a name does not bring an action into existence.
• Risk decided by the system, not the plan. The risk class of an action comes from your registry, never from the model’s own description of what it wants to do.
• A named approver. High-risk actions wait for a specific human, and the approval is recorded under that person’s name. “Someone clicked yes” is not accountability.
• Refusals on the record. A denied action is written down with its reason. The refusal is evidence, and it is the half of the story most systems throw away.

Why is a confirm dialog not enough?

A yes/no prompt fails all four properties: it approves whatever string the model produced (open set), trusts the model’s framing of risk, records no approver identity, and leaves no trace when someone clicks no. It creates the feeling of control and none of the record. Under review, the difference is fatal.

A working pattern: propose, decide, record

The model proposed exec_shell. It was not registered, so it could not run, whatever the plan claimed about it. The decision, including the refusal, is written to the record. That is the shape of a defensible gate: the authority lives in code you wrote, and every exercise of it leaves evidence.

Where do the waiting questions go?

A gate produces questions a human has to answer: approve this high-risk repair, resolve this rule violation, decide whether two records are the same person. In OMEM those wait in a judgment queue; each decision is recorded under the decider’s name, and a dismissed question is never asked twice. The queue ships in the open-source dashboard.

How does this connect to the audit trail?

Approvals are one half of accountability; the other half is proving why the agent believed what it believed when it acted. Together they answer the two questions every client review asks: who allowed it, and on what basis. The belief half has its own guide: an audit trail for AI agents.