Why architecture matters here
Human-in-the-loop gating is architectural because it is the control point where an agent's autonomy is deliberately bounded, and where the responsibility for a high-consequence action is transferred from the model to a person. An agent's power comes from acting without asking; its danger comes from the same thing. You cannot make an agent both fully autonomous and fully safe on irreversible actions, because safety on those actions requires a judgment the model cannot be trusted to make alone — it can be wrong, and it can be manipulated. The gate is the mechanism that resolves this by inserting human judgment precisely and only where it is needed, so the agent stays fast on the many safe actions and accountable on the few dangerous ones.
The central design decision is where to draw the line between auto-execute and require-approval, and getting it wrong in either direction fails. Set the threshold too low — require approval for too much — and you drown reviewers in requests, most of them obviously fine, which trains them to approve without looking; the gate becomes a rubber stamp and provides no real protection while destroying the agent's speed. Set it too high — auto-execute too much — and genuinely dangerous actions slip through unreviewed. The threshold is therefore the most important parameter in the system, and it must be set by the risk and reversibility of the action, not by uniform policy: the goal is that when a human is asked to approve, the request is non-obvious enough that their attention adds real safety.
Reversibility is the concept that makes the threshold tractable, and it deserves to be a first-class input to the classifier. An action you can cleanly undo is fundamentally lower-risk than one you cannot, because the cost of a mistake is bounded — you reverse it and move on. A reversible action can often be auto-executed even if it is significant, because a wrong one is recoverable; an irreversible action — money sent, data destroyed, an email delivered to a customer — deserves human approval even if it seems routine, because a wrong one cannot be taken back. So the architecture does not just classify by 'how big is this action' but by 'can we undo it', and it actively prefers designs where consequential actions are staged reversibly (a draft, a soft delete, a pending transaction) so that fewer actions need to block on a human at all.
The subtlest architectural requirement is that the gate must resist the human failure mode it depends on, which is that people are bad at vigilant approval of a high-volume, mostly-benign stream. This is the same reason review theater plagues change management: a reviewer shown hundreds of nearly-identical approve prompts stops reading them, so the very mechanism meant to add safety adds none. The architecture fights this on two fronts. First, it keeps the approval stream small and high-signal by auto-executing everything safe, so a human is only interrupted when it genuinely matters and each request carries weight. Second, it gives the reviewer real context — what the agent is trying to do, why, on what data, and what the consequence is — so that approving is an actual decision rather than a reflex. A gate that shows a reviewer a bare 'allow this tool call?' with no context is engineering the reviewer into rubber-stamping; a gate that shows the concrete effect, the diff, the blast radius is engineering them into judgment. The security value of the whole architecture rests on keeping human review meaningful, which means the design must actively protect the reviewer's attention as the scarce, degradable resource it is.
The architecture: every piece explained
The top row is the routing decision. The agent proposes an action — a tool call, an API request, a state change — rather than executing it directly; proposal-then-gate is the structural inversion that makes oversight possible. The risk classifier scores the proposed action, assigning it a risk level and category based on what the action does, how reversible it is, and what it touches. Based on that score the action takes one of two paths: auto-execute for low-risk, reversible actions that run immediately without a human, or the approval queue for high-risk actions that are held until a person decides.
The middle row is the approval workflow. The reviewer UI presents a held action with full context — what the agent wants to do, why, the concrete effect (a diff, the exact query, the recipient and content), and the blast radius — so the reviewer can make a real judgment rather than a blind one. The timeout policy governs what happens if no one responds: a held action must fail safe, meaning it is denied or kept holding rather than silently executed, because timing out into execution would defeat the gate. The decision is the reviewer's verdict — approve, deny, or edit the action before it runs — and on approval the action moves to execute and record, where it finally runs and the outcome is logged.
The third row holds the two policies that harden the gate. The reversibility check is the design preference for actions that can be undone: wherever possible, consequential operations are staged as reversible (drafts, soft deletes, pending transactions) so a mistaken approval is recoverable and fewer actions need to block at all. The escalation path routes the most critical actions — the largest, most irreversible, most sensitive — to a more senior or a second reviewer, so that the highest-consequence decisions get proportionally more scrutiny rather than being approved by whoever happens to be on the queue.
The ops strip names the operating discipline. The risk threshold must be tuned so reviewers see the right volume of high-signal requests; approval latency must be watched because a slow queue makes the agent slow and tempts operators to weaken the gate; every decision must be audited so that both approvals and denials are attributable after the fact; and the system must actively guard against rubber-stamping — through context, escalation, and monitoring of approval patterns — because a gate that is reflexively approved is no gate at all.
End-to-end flow
Follow a routine action. An agent assisting with a task decides to read a record and draft a summary. The risk classifier scores this as low-risk and reversible — it reads data the agent is authorized to see and produces a draft that changes nothing — so it auto-executes. No human is interrupted, the agent stays fast, and the reviewer's attention is not spent on something that did not need it. This is the common case, and the architecture's job is to make it the common case: the vast majority of an agent's actions should flow through the auto-execute path so that the approval queue stays small and meaningful.
Now a dangerous action. The same agent, continuing the task, decides to send an email to an external customer. The classifier scores this as high-risk and irreversible — an external communication cannot be unsent — so it is held in the approval queue rather than executed. A reviewer opens the request in the reviewer UI and sees the full context: the recipient, the exact subject and body, why the agent decided to send it, and the fact that the content was partly derived from a document the agent read. That context lets the reviewer notice, for instance, that the email contains a phrase that looks like it was injected by the source document, and deny the action — or edit the body and then approve. The gate did its job precisely because the reviewer had enough context to catch a problem a bare confirm dialog would have hidden.
Consider the timeout case, which is where fail-open bugs hide. A high-risk action is queued, but it is after hours and no reviewer responds within the timeout window. The correct behavior is to fail safe: the action is denied (or remains held) and the agent is told its action was not approved, so it can surface the blockage rather than proceeding. The dangerous, wrong behavior — one that creeps in when timeouts are treated as a UX annoyance rather than a security control — is to let the action execute when the timer expires 'so the agent isn't blocked'. That converts the gate into a delay: anything a reviewer ignores long enough runs anyway, which an attacker who can time their injection for off-hours will happily exploit. The timeout policy must default to safety, and the operational fix for legitimately blocked work is faster reviewers or better escalation, never auto-approval.
Finally, the escalation and audit case. An agent proposes an action at the extreme end of the risk scale — say, a bulk deletion or a large financial transfer. Rather than being approved by any first-line reviewer, it escalates to a senior approver or requires two approvals, because the consequence justifies more scrutiny. Whatever the outcome, the decision is written to the audit log with who decided, when, what they saw, and the action's full detail. That record matters for two reasons: after an incident it answers 'who approved this and on what basis', and over time it lets you monitor approval patterns to detect rubber-stamping — a reviewer who approves everything in two seconds is a signal the gate is degrading into theater. The audit trail is thus not just for forensics; it is the feedback loop that keeps the human part of the human-in-the-loop honest, which is the whole point of building the gate in the first place.