AI agents
Human in the Loop: What an AI Agent Should Never Send Unapproved
Human in the loop is used to mean everything from a dashboard someone might check to a mandatory approval gate. The difference decides whether an agent is deployable against real vendors and customers.
A meaningful human-in-the-loop design requires a named person to approve before any action leaves the organisation, and records the decision. Designs where a human can review afterwards, or is notified in parallel, are not controls, because nothing stops the action.
- Review after the fact is not a control. Nothing was prevented.
- Approval must be blocking, named and recorded to mean anything.
- If approving costs more than doing it manually, the gate gets removed within a quarter.
Three things the phrase is used to mean
Only one of them is a control.
Human on the loop. The agent acts; a human can review afterwards. Appropriate for reversible internal actions. Not a control for anything that leaves the organisation, because by the time anyone reviews, the message is sent.
Human in parallel. The agent acts and notifies simultaneously. Marketed as oversight. It is a notification.
Human in the loop. The agent prepares; nothing happens until a named person approves. The only version that prevents anything, and the only one an assessor can test.
What should always be blocking
- Any message to a vendor. A commercial act in a relationship you continue to hold. A wrong escalation damages the credibility of the next correct one.
- Any message to a customer. Obvious in principle and routinely eroded in practice by "low-risk" templates.
- Configuration changes. Disabling an integration or altering retry behaviour has consequences invisible in the signals that prompted it.
- Severity changes others rely on. Severity encodes commercial context the agent does not have.
- Closing an incident. Requires judging whether a fix held, which is judgement rather than observation.
Time saved by sending automatically: seconds. Cost of one wrong message to a vendor you depend on: a damaged relationship and a weakened position at renewal. These are not comparable quantities, which is why the boundary belongs here regardless of how good the drafts get.
What makes approval real
Four properties, and all four are necessary.
Named. A specific person, not a group alias. Group approval is diffused approval, and diffused approval is nobody checking carefully.
Blocking. Nothing proceeds without it. No timeout that auto-approves, which is the most common way a real gate quietly becomes a notification.
Informed. The evidence arrives with the request. An approver who must open three tools to verify will stop verifying by the second week.
Recorded. Who approved, what, and when. This is what an auditor asks for, and it is also what makes the gate credible internally.
The failure mode to design against
Not a wrong message getting approved. It is approval becoming a reflex.
An approver facing forty requests a day stops reading by the second week, and you have automation with extra steps and a worse audit story, because now there is a name attached to decisions nobody actually made.
The defence is volume discipline rather than better approval tooling. If the agent requests approval forty times a day it is surfacing too much, which is the problem described in alert fatigue wearing different clothes. A system with judgement should request approval rarely enough that each request is read.
Why restraint sells
Counterintuitively, the restrictive design deploys faster.
Security review is the last gate before signature on most enterprise deals and the slowest to clear. "Every outbound action requires a named approver and the decision is recorded" is testable. "The model is careful" is not, and the difference is measured in deal cycles.
It is the reason Traxivo holds every outbound message rather than optimising for autonomy: the agent drafts the escalation with six months of history attached, and then waits. The waiting is the feature, not the limitation, and it is what makes the thing deployable against vendors you have to keep working with.
Frequently asked questions
What does human in the loop actually require?
A named person must approve before the action occurs, the approval must block rather than notify, the evidence must arrive with the request, and the decision must be recorded. Designs where a human reviews afterwards prevent nothing.
What should never be sent without approval?
Anything leaving the organisation, which means messages to vendors or customers, plus configuration changes, severity changes others rely on, and closing an incident. Each is either irreversible or depends on context the agent does not hold.
How do you stop approval becoming a rubber stamp?
Limit volume. An approver facing dozens of requests a day stops reading within weeks. A system exercising genuine judgement should request approval rarely enough that each request is actually examined.
Stop rediscovering the same integration failure
Traxivo correlates the signals your tools already produce into one incident timeline, recognises a recurrence as a recurrence, and drafts the follow-up with the evidence attached. Nothing is sent without a named approver.
See how Traxivo works Browse use cases
