Oversight architectures: HITL, HOTL, HOOTL

Three system shapes for human oversight, and which decisions belong in each.

Match oversight to decision risk

Not every decision needs the same level of human involvement. Over-approving low-risk decisions causes approval fatigue. Under-approving high-risk decisions is how things end up in the press.

The risk × complexity matrix is the quickest way to find the right fit.

Reading the matrix

• Axes. Vertical = risk of a wrong outcome (low to high). Horizontal = complexity of the decision (simple to ambiguous). Hover any cell to read its pattern.
• Low risk, low complexity → Independent AI. Acts without supervision. Think classification of spam or routing rules.
• Low risk, high complexity → AI operator with edge-case review. The agent handles normal traffic; humans review anything flagged.
• High risk, low complexity → AI as collaborator. Recommends; human validates before any execution. A simple decision can still be irreversible.
• High risk, high complexity → Human only, with AI support. The AI informs; the human decides. If this cell applies and you still want to delegate, you are not ready.

The three canonical oversight architectures

The matrix tells you how much human involvement a decision needs. The three architectures — HITL, HOTL, HOOTL — are how you implement it. They are not three flavours of the same thing; they are three different system shapes, with different runtime behaviour, different infra, and different failure modes.

If you read only one section of this lesson, read these three.

Human-in-the-loop (HITL) — the agent proposes, the human commits

Shape. The agent reaches a decision point, pauses, and hands a proposed action to a human. Nothing executes until the human approves. Rejection sends the proposal back (or kills it).

Who triggers what. The agent triggers the pause. The human is the only entity authorised to trigger the side-effecting call — the agent can't execute the tool itself; it can only ask.

What you need to build.

• A proposal queue — persistent, with a clear schema for "what will happen if approved".
• A review UI that shows the proposed action, the agent's reasoning, and the evidence it used (retrieved docs, tool outputs) in one place.
• Timeout behaviour. What happens if nobody approves in 4 hours? 4 days? Define it — silent expiry is a common incident root cause.
• An audit record that links the approver's identity to the executed action. Without this you have a technically-HITL system that is legally indistinguishable from HOOTL.

When it fits. Medium-to-high-risk actions, low-to-medium volume. Refund over £500. A contract clause change. A first-time tool invocation by a newly-deployed agent. Anything irreversible.

Failure modes.

• Approval fatigue. Humans rubber-stamp once the queue is long or the proposals look similar. Mitigations: risk-tier the queue so only decisions that need judgement are HITL; batch and dashboard the rest.
• Queue starvation. Reviewers go on holiday and the agent becomes useless. Plan coverage.
• Theatre approvals. The proposal format hides the actual consequence. Make "what will happen" concrete, not a summary.

Human-on-the-loop (HOTL) — the agent acts, the human can stop it

Shape. The agent executes in real time. Its decisions and tool calls stream to a monitoring surface where a human can intervene — pause, correct, roll back. Actions are not blocked on approval; they are observable and interruptible.

Who triggers what. The agent triggers its own actions. The human has a kill switch, a correction channel, and (often) the power to requisition the agent's state mid-run.

What you need to build.

• Live telemetry. Tool calls, reasoning summaries, state changes — streamed with sub-second latency to the oversight UI.
• A real kill switch that halts the agent and any subagents it has spawned. Children don't stop when the parent dies by default. Design for that.
• Rollback or compensation mechanisms for side-effecting actions. A kill switch that stops the next action but leaves a half-sent email is not useful.
• Alerting on anomalies — so the reviewer isn't watching a boring dashboard waiting for something to go wrong.

When it fits. Time-sensitive actions where waiting for HITL approval would defeat the purpose. Incident-response bots. Customer-call copilots. Trading-adjacent agents where a milliseconds-to-seconds intervention window is meaningful.

Failure modes.

• Attention decay. A human watching a steady-state dashboard for four hours will miss the one interesting event. Rotate reviewers; alert on anomalies, not just errors.
• Intervention is too slow. By the time the human sees the problem, the action has committed. Either move the class of decision back to HITL, or add a short built-in delay ("pause 500ms before emailing, unless the reviewer confirms within 250ms").
• Silent child processes. Subagents keep running after the kill switch. Test that every oversight session actually halts the whole tree.

Human-out-of-the-loop (HOOTL) — the agent acts, the audit catches up

Shape. The agent runs fully autonomously. Humans interact with the agent's behaviour only through dashboards, weekly reports, sampled reviews, and post-incident forensics. There is no real-time pause or approval.

Who triggers what. The agent runs on its own timeline. Humans trigger investigations and policy changes, not individual decisions.

What you need to build.

• Complete, queryable action logs — every tool call, every input, every output. If it isn't logged, it didn't happen from an audit perspective.
• Risk-tiered sampling of actions for post-hoc human review — 100% of high-risk actions, some fraction of the rest. See the HITL review lesson.
• Drift detection and anomaly alerts on the distribution of actions, not just individual errors. A HOOTL agent that suddenly changes its behaviour after a model upgrade is the classic silent-failure case.
• Circuit breakers — automatic stops on spend limits, call-rate thresholds, or unusual tool usage. Without these, a runaway HOOTL agent is the bet-the-company risk.
• A kill switch anyway. Operated by an on-call human, not the agent itself.

When it fits. Low-risk, high-volume, reversible work where real-time oversight would be uneconomic and unnecessary. Email triage. Low-tier support routing. Log-parsing. Content classification. The REMIT-M (Monitoring) pillar has to be solid; without it, HOOTL is just "unsupervised".

Failure modes.

• Silent drift. A model update changes behaviour subtly and nobody notices for weeks. Monitor distributions, not just errors.
• Scope creep. An agent deployed for one HOOTL use case gets wired into a second higher-risk use case without revisiting the oversight model. Review annually.
• Blind confidence. Teams mistake absence of alerts for absence of problems. Schedule sampled audits whether or not anything looks wrong.

Side-by-side comparison

Which should I pick?

Read down the list; the first yes is your answer.

1. Is the action irreversible, regulated, or above your blast-radius threshold? → HITL, at least until you have months of evidence.
2. Is the action time-sensitive in a way that makes per-action approval absurd (sub-minute decisions), but still reviewable in real time? → HOTL.
3. Is the action low-risk, high-volume, and reversible — and do you have real monitoring and circuit-breaker infra? → HOOTL.
4. None of the above? → You probably want HITL, or you're not ready to deploy.

Most production agents use a blend. A single customer-support agent might run HOOTL on tier-1 triage, HOTL on draft replies, and HITL on refunds over £500. That is the matrix and the three architectures doing their jobs together — cell by cell.

How this maps to authority levels

The matrix, the three architectures, and the five-tier authority level ladder are three views of the same thing. If you know which matrix cell a decision belongs to, you know which architecture and which authority level it gets.

Worked example

A refund agent.

• Simple, low-risk (refund under £50 for a known cancellation code) → HOOTL / Independent AI. Auto-approve.
• Medium risk (refund £50–£500) → HOTL / AI as executor. Auto-approve, reviewer watches the stream, samples 10% post-hoc.
• High risk (refund over £500, or policy exception) → HITL / AI as collaborator. Agent proposes with reasoning and evidence; a named human approves before the payment call fires.
• Out-of-policy (refund that requires a policy change) → No agent. Human only.

You ship all four cells in a single agent, differentiated by code-enforced envelope rules. That is REMIT-E, the matrix, and the three architectures doing their jobs together.