Most teams already say they keep a human in the loop. Pressed on what that means, the honest answer is usually a Slack message and a thumbs-up emoji. The agent did the work, posted a summary to a channel, someone glanced at it, and the agent carried on. Nobody can say who approved it, what they were approving, or whether they could have stopped it if they had wanted to.
A "human in the loop" that the agent can ignore is not a control. It is a courtesy. The distinction matters most at the exact moments regulators care about: the decisions you cannot take back.
One-way doors
Some actions are reversible. An agent drafts an email, you don't like it, you delete the draft. No harm done. Most agent work is like this, and most of it should never wait on a human at all — gating everything trains people to rubber- stamp everything.
Other actions are one-way doors. Once they happen, the world has changed and you cannot quietly walk it back:
- A suspicious-activity report is filed with the regulator.
- A drug batch is released to the market.
- A configuration is pushed to live medical devices in the field.
- Money leaves an account.
These are the moments a real human-in-the-loop control exists for. The job of an approval gate is to recognise a one-way door before the agent walks through it, and to stop the run there until a named person decides to open it. Not to advise. To decide.
A gate is a workflow step, not a notification
Here is the design error almost everyone makes. They treat the approval as something that happens alongside the work — a notification fired off in parallel while the agent keeps moving. The agent acts; the human finds out.
A real approval gate is the opposite. It is a step in the workflow, on the critical path, and the run physically cannot continue past it. In MakerChecker a gate is a first-class element of a Flow — the same kind of object as a tool call or a skill grant, not an annotation bolted onto one. When the run reaches the gate, it parks. It is not blocked by a timeout or a polite prompt. The execution state is frozen at that point and held until the gate resolves, no matter how long that takes.
The difference is enforcement. A notification can be missed, muted, or overtaken by an agent that decides to proceed anyway. A parked run has nowhere to go. The one-way door stays shut because the workflow has no path through it except a human signature.
This is what separates an approval gate from a guardrail. A guardrail asks "is this content dangerous?" and the agent flows on if the answer is no. A gate asks "is this actor authorised to walk through this specific door, right now?" and the answer is held open until a person provides it. The two are complementary — you want both — but only one of them stops a run cold.
What a signature has to mean
Parking the run is half the control. The other half is making the signature worth something.
Three properties turn a click into evidence.
A named signer. The approval is attributed to a specific, identified person — not a service account, not a shared inbox, not "the on-call rota." When an examiner asks who released the batch, the answer is a name, tied to a credential, recorded at the moment of signing. This is the spirit of 21 CFR Part 11 signature manifestations (11.50) and signature- to-record linking (11.70): a signature has to say who signed, what they signed, and why, and it has to stay stuck to the record it approved.
A captured reason. The gate records the signer's stated reason, verbatim, at the time of approval. Not a checkbox. The words. Six months later, when discovery arrives, "approved because the alert matched a known false-positive pattern from the same counterparty in March" is a defensible decision. A green tick is not.
Requester exclusion. The person — or agent — who requested the action cannot be the one who approves it. This is the maker-checker principle, the four-eyes control that finance and quality assurance have run on people for a century, now enforced structurally on machines. In MakerChecker the same agent provably cannot be both maker and checker on one run; the attempt is refused, and the refusal itself lands in the audit trail. The four-eyes principle for AI workflows goes deeper on why "provably cannot" beats "is not supposed to."
Quorums, when one signature isn't enough
Not every door takes the same number of keys. Some decisions are weighty enough that one named human is not the bar — you want two, or three, or two from a specific group.
An approval gate supports n-of-m quorums: require any two of five authorised approvers, or one from compliance plus one from operations, before the run proceeds. The requester is excluded from the count, so a maker cannot pad their own quorum. The gate holds until enough of the right people have signed, and each signature carries its own name and its own reason.
| Decision | Typical gate |
|---|---|
| Routine internal draft | No gate — reversible |
| File a suspicious-activity report | One named compliance signer, reason captured |
| Release a GMP batch | Qualified Person sign-off, requester excluded |
| Push config to live devices | Two-of-N quorum, captured reasons |
EU GMP Annex 16 already names the Qualified Person who must personally certify a batch before release. NYDFS Part 504 and the Wolfsberg guidance already name the human decision in an AML program. A suspicious-activity-report filing under the BSA is, by law, a human decision. The predicate rules already say a named person must sign these doors. An approval gate is simply where that requirement gets enforced when the worker proposing the action is an agent instead of an analyst.
The thing you can hand an inspector
When the run finally proceeds, every part of the gate is in the record: which door, who signed, when, what reason they gave, who was excluded, and the fact that the run waited until they did. That record is part of a hash-chained, cryptographically signed audit export that a third party can verify offline — without access to your systems and without having to trust the vendor. Alter one approval after the fact and the chain visibly breaks.
That is the whole point. A human-in-the-loop control is only as good as your ability to prove, later, that the human was actually in the loop — that the door was shut, that a named person opened it, and that they said why. Everything short of that is a thumbs-up emoji you cannot find again when it matters.
For the regulated context behind these gates, see financial services and life sciences. For why this is urgent even though there is no agent-specific supervisory template yet, read the case for why now.
An approval gate should park the run, exclude the requester, and capture the reason — every time. See how it works, or book a demo to watch an agent get blocked from approving its own work, live.