Capability
Human-in-the-loop approvals
A human-in-the-loop approval pauses an agent before a consequential action and asks a person to decide. It is the control executives ask for by name and the one that most often degrades into theatre — because an approval that arrives without context, or arrives fifty times a day, gets approved without being read.
Which actions deserve a pause
The instinct is to gate everything important. That produces a queue nobody reads. The better test has two parts, and an action needs both.
Is it hard to undo? A wrongly-tagged ticket is a correction. A transfer, a public post, a granted permission, a deleted record and a sent external email are not — they have left your control.
Can a human actually add judgement? This is the part usually skipped. If the reviewer has no information the agent lacked, the approval adds delay and an audit trail but no decision. That is worth knowing you are doing deliberately, rather than believing you have a control.
| Action | Hard to undo? | Human adds judgement? | Gate? |
|---|---|---|---|
| Refund above a threshold | Yes | Yes — context on the customer | Yes |
| Grant a permission | Yes | Yes — knows the person | Yes |
| Email an external party | Yes | Yes — tone and accuracy | Yes |
| Delete a record | Yes | Rarely — reviewer usually knows less | Prefer soft-delete and a rate limit |
| Update a ticket field | No | — | No. Log it |
Why approval queues stop working
Three failure modes, and they compound.
Volume
Past roughly a dozen a day per reviewer, approvals become a rhythm rather than a decision. The click-through rate on an approval queue is the real measure of whether the control exists, and almost nobody tracks it.
Missing context
"Agent wants to send an email. Approve?" cannot be answered. The reviewer needs the recipient, the content, what prompted it and what the agent was asked to do. If the approval does not carry those, the reviewer either approves blind or goes and finds them — and the second only happens twice.
No expiry path
An approval nobody answers has to do something. Silently blocking strands the work; silently proceeding makes the gate decorative. The honest design states the timeout and what happens at it, per action class, and reports how often it fires.
The number worth watching is not how many approvals were granted. It is how many were rejected. A queue with a rejection rate near zero is not protecting anything — either the thresholds are wrong or nobody is reading.
Designing one that survives
Put it where the person already is. An approval in a tool someone opens once a week is a delay, not a control. Chat and email are where these get answered.
Carry the whole decision. What is being attempted, on what, why, what it cost or affects, and what happens if nobody answers.
Let rejections teach. A rejected approval is evidence about where the threshold should sit. If rejections do not feed back into the rules, you have built a queue instead of a policy.
Review the volume on a schedule. Approval load should fall over time as rules absorb the obvious cases. If it is flat or rising, the control is drifting toward theatre.
Name a fallback and test it. Every gate has a person behind it, and people are on leave, asleep or in meetings. An approval path with one named reviewer and no second is a single point of failure on the agent's ability to do its job — which is how gates get quietly disabled rather than escalated.
Where Agent Trust Cloud fits
| Need | What the platform does |
|---|---|
| Pause an action for a person | Approval is one of the outcomes a policy can produce at Runtime, alongside monitor, warn and block |
| Decide which actions pause | Policy Engine holds the conditions, so the threshold changes without touching the agent |
| Evidence for an auditor | Audit Ledger records what was attempted, who decided and what followed |
| Make reviewers read carefully | No software does this. The only real defence is keeping volume low enough that each one still feels like a decision |
| Decide your thresholds | Yours. This is a question about acceptable loss and it belongs to whoever owns the consequence |
Common questions about human-in-the-loop approvals
How many approvals per day is too many?
Past roughly a dozen per reviewer, attention degrades and approval becomes a rhythm. There is no exact number, but there is a reliable signal: track the rejection rate. A queue that rejects almost nothing is either gating the wrong actions or not being read, and both mean the control is not doing what its existence implies.
What should happen when nobody answers an approval?
Something explicit, stated per action class, and reported on. Silently blocking strands work and teaches people to route around the control. Silently proceeding makes the gate decorative. Most deployments want a timeout that blocks for irreversible actions and escalates rather than proceeds — but the important part is that it is a decision on record rather than an accident of implementation.
Does an approval gate slow the agent down too much?
It will if you gate the wrong things. The reason to apply two tests — is it hard to undo, and can a human add judgement — is that actions failing the second test cost latency and produce nothing. Gating a handful of genuinely consequential actions is barely noticeable; gating everything important removes the reason the agent was deployed.
What information does a reviewer actually need?
What is being attempted, against what, what prompted it, what it costs or affects, and what happens if they do not respond. An approval that omits any of these forces the reviewer to go and find them, which happens roughly twice before they start approving blind.
Is a human-in-the-loop approval the same as an audit trail?
No, though they are often conflated in compliance conversations. An audit trail records what happened. An approval changes what happens. You can have a complete trail of actions nobody could have stopped, which satisfies an auditor asking for evidence and does nothing for the risk itself.