"Human in the loop" sounds safe, but it can describe two very different systems. In one, a person checks every minor detail and the agent saves almost no time. In the other, someone routinely clicks "Confirm" without understanding the planned action. Both are weak controls.
Human approvals should be placed where a decision has consequences. The position of each approval should reflect impact, reversibility, uncertainty and data sensitivity.
Which Actions Require Approval?
Approval is particularly useful when the agent:
- sends external communications,
- modifies or deletes business data,
- affects money, contracts or access rights,
- transfers sensitive data to a new recipient,
- prepares a decision with consequences that are difficult to reverse.
Pure research or the creation of an internal draft can often run automatically, provided sources, scope and costs are limited.
Review Before the Action or After the Result?
There are two distinct control points. Before an action, the human reviews the intent and parameters. This is important for tool calls with real-world impact, such as sending a message or changing a record.
After execution, the human reviews the result. This works for drafts, analyses or recommendations. For irreversible actions, a retrospective review comes too late.
A good workflow can combine both: The agent first creates a draft, then presents the planned change as a preview and executes it only after confirmation.
What a Useful Approval Must Show
An approval interface should not merely ask whether the agent may continue. It should show:
- which action will be performed,
- which system and record it affects,
- which data will be sent or changed,
- which source and reasoning support it,
- whether the action can be reversed,
- what alternative applies if it is rejected.
The reviewer must be able to recognise the difference between "save draft" and "send to all customers" immediately.
Avoid Approval Fatigue
Too many confirmations lead to blind clicking. Group low-risk steps and require approvals only at clear decision boundaries. Recurring actions can be automated more narrowly after a successful pilot if evaluation, logging and rollback mechanisms work.
Approvals should also be role-based. A subject-matter expert can review factual correctness, while a person responsible for the system assesses the data flow or access rights.
Rejection Is a Normal System Path
An agent must be able to handle "No." After a rejection, it should not propose the same action again with slightly different wording. It needs a defined path: adjust the task, obtain missing information, escalate to another role or stop.
Record reasons for rejection in a structured form. They reveal where prompts, data, tools or rules need improvement.
How Do You Measure the Value of Human Review?
Do not measure only the number of approvals. Relevant metrics include:
- the proportion of actions rejected or changed,
- reasons for changes,
- the time required for review,
- errors prevented before execution,
- actions that can be automated after stable evaluation.
If almost every approval is confirmed without review, the control point is probably poorly designed. If almost every action is changed, the agent is not yet ready for that degree of autonomy.
Sources
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- European Commission, Ethics Guidelines for Trustworthy AI: https://digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai
- OpenAI, Building guardrails for agents: https://openai.github.io/openai-agents-python/guardrails/
- OWASP Agentic AI Threats and Mitigations: https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
Next Step
Map an agent workflow as a sequence of concrete actions. Mark every point where data leaves the system, business data is changed or a result becomes difficult to reverse. Place approvals only at those boundaries and test whether the reviewer can understand the planned impact in less than one minute.