Human approval patterns for AI agents
Written by: Artashes Arakelian, Co-founder & COO · Published: · Updated:
An AI agent that can act needs a clear rule for when a person decides. This article compares four approval patterns, what each should log, and how to roll them out in order.
Approval is a design decision, not a checkbox
When an AI agent can send an email, change a record or trigger a payment, the question is no longer whether the model is clever but who decides, and when. Saying that a human is in the loop is not enough, because the phrase can mean a person reads every output or that someone could in theory switch the system off. Both are very different in cost and in protection. We treat approval as a design decision made per action: which actions the agent may take alone, which need a person first, and what happens when something goes wrong. The patterns below are how we usually answer those three questions in our own orchestration work.
Four patterns, and what they are not
The four patterns in this article are our own engineering practice. They are patterns, not legal requirements, and nothing here claims that using one of them makes a system compliant with the EU AI Act or any other law. They are useful because each one sets a different balance between speed, cost and control, and because each one produces a record that a person can later review. In practice most agents use more than one: a kill switch everywhere, and one of the other three per action type.
The four patterns side by side
The table compares the patterns by the situation they suit and by the minimum record each should leave behind. Read it per action rather than per agent: the same agent can use pre-approval for payments and sampled review for tagging support tickets.
| Pattern | When to use | What to log |
|---|---|---|
| Pre-approval: the agent proposes, a person approves before anything happens | Actions that are hard to reverse, visible to customers or partners, or costly when wrong, such as payments, contract changes or external messages | The proposed action, the inputs and sources shown to the approver, who approved or rejected, any edits made, and the time |
| Exception queue: the agent acts alone on clear cases and sends unclear ones to a person | High volume with mostly routine cases, where you can describe in advance what counts as unclear | Why each item was routed (rule or low confidence), time waiting, the person's decision, and the share of items routed |
| Sampled review: a person checks a sample of completed actions afterwards | Low-risk, reversible actions at volume, where per-item approval would cost more than the errors it prevents | The sampling rule, which items were drawn, the reviewer's verdict, errors found and the corrective action taken |
| Kill switch: any authorised person can stop the agent immediately and return work to manual handling | Always, as a backstop behind every other pattern, and the only pattern for sudden problems such as a bad data feed | Who stopped it, when, why, what was in flight at that moment, and who approved the restart |
How to choose per action
Two questions decide most cases. How expensive is one mistake, and can it be undone? An action that is costly or irreversible belongs behind pre-approval, however accurate the agent looks in testing. An action that is cheap and easy to undo can run alone and be checked by sampling. The exception queue sits between them: it works when you can state clearly what makes a case unusual, for example a missing field, an amount above a limit or a customer on a watch list. If you cannot describe the exceptions, you do not yet know enough to leave the routine cases unattended, and pre-approval is the honest choice.
Make the approver real
A person who clicks approve on every item without reading is not oversight, only latency. Three details make approval real. Show the approver the evidence behind a proposal, not only the proposal. Give them the authority to reject without asking permission, and the time to review at the pace the queue arrives. Tell them how the system tends to fail, so that they look for those failures instead of trusting a confident tone. Logging the edits an approver makes is useful here: a high rate of unchanged approvals on complex items is a signal to check whether the review is happening at all.
What the AI Act says about oversight
For high-risk AI systems the AI Act addresses human oversight directly. According to the European Commission's AI Act Service Desk, Article 14 requires providers to design such systems so that people can oversee them effectively while in use, and lists capabilities for those people: understanding the system's limits, staying alert to over-reliance on its output, interpreting it, choosing not to use or overriding it, and stopping it safely. Article 26 places duties on deployers: use the system according to its instructions, assign oversight to people with the necessary competence, training and authority, monitor operation, and keep the logs under their control for at least six months. Those articles concern high-risk systems only, and the Service Desk notes that its summaries are not legally binding. Which of your uses count as high-risk, and from when, is a question for a legal adviser; our timeline article covers the dates. The patterns above can support such duties, but they are not a substitute for reading the text.
A rollout order that holds up
Rolling out approval in the wrong order is the usual mistake: teams start with the lightest control because it is cheapest and add friction only after an incident. The order below reverses that. It moves from strict to light as the record shows the agent can be trusted with more.
- List every action the agent can take and mark each as reversible or irreversible and as internal or external.
- Put every action behind pre-approval at the start, including those you expect to relax later.
- Define the log fields before launch: proposal, evidence, person, decision, time and any edit.
- Name the approvers, give them authority to reject, and agree a maximum time to respond.
- Build and test the kill switch before the first live action, and rehearse who may use it and how work reverts to manual.
- After enough logged decisions, move low-risk actions to an exception queue and the lowest-risk to sampled review, one action type at a time.
- Review the logs, sample results and stop events on a fixed schedule, and move an action back to pre-approval if errors rise.
Keep the record, keep the right to stop
The same principle runs through all four patterns: the person must be able to decide, and the organisation must be able to show afterwards what was decided. Approval without a log cannot be reviewed, and a log without a working way to stop the agent only documents the problem. If you are planning an agent that acts on your systems, treat the approval design as part of the build from the first workshop, because retrofitting it after launch usually means rewriting how the agent reports its work.
Frequently asked questions
What is the difference between human in the loop and human on the loop?
In the loop means a person decides before each action, as in pre-approval. On the loop means the agent acts alone while a person monitors, intervenes on exceptions or reviews samples afterwards. Which one fits depends on how costly and how reversible a mistake is, not on the technology.
Do these approval patterns make an AI agent compliant with the AI Act?
No. They are engineering practice, not legal requirements. The AI Act's human oversight rules for high-risk systems sit in Articles 14 and 26, and whether your use is high-risk is a legal question. The patterns and their logs can support those duties, but they do not prove compliance.
How do I know when an agent can move off pre-approval?
Use the record. When a meaningful run of logged decisions shows approvers rarely change or reject a given action type, and errors are cheap to undo, move that type to an exception queue or sampled review. Keep the kill switch, and move back if errors rise.