Governance & ReBAC · 8 min min read
Human-in-the-loop as a first-class primitive (not a workaround)
Human-in-the-loop for AI agents should be a runtime primitive, not a bolt-on approval queue. How Oraclous treats waiting on a human like waiting on a tool return.
Most agentic tools treat human oversight as an afterthought: a webhook fires, a Slack message lands, a dashboard waits for someone to notice. The agent has already moved on; the human is a side-channel bolted on beside the machine. That design fails exactly when it matters — under load, on the high-stakes step, the moment review gets skipped. Oraclous makes a different choice. Human-in-the-loop is a runtime primitive: the platform treats waiting on a human like waiting on a tool to return. Same primitives, different latency. This post explains why that distinction is the whole game for anyone putting agents near consequential work.
Citable answer — What is human-in-the-loop as a first-class primitive? It means human review is built into the runtime rather than bolted on beside it. In Oraclous (Platform Architecture §5), the Harness Runtime treats waiting on a human like waiting on a tool return — same primitives, different latency — so the run pauses and persists at the gate until a person acts, then resumes. Because the gate is coded enforcement, a Harness’s prose cannot route around it; a human can block a step and the runtime obeys.
First-use glossary terms: Human-in-the-loop (HITL) is the assignment of a Harness step to a human for review, approval, or action; an Actor is any entity — human member or AI Agent — that can be assigned work; a Harness is the goal-driven assembly those Actors work in; an Operator is the person who states the goal in prose; and ReBAC is access by relationship rather than by static role. The thread running through all of them is symmetry: humans and Agents are the same kind of thing to the runtime, which is exactly what lets a human be a step rather than an interruption.
What does “waiting on a human like waiting on a tool return” mean?
It means the runtime has one notion of “a step that hasn’t finished yet,” and a human approval is an instance of it. When an Agent calls a tool, the runtime dispatches the call and waits for the result. When a Harness reaches a human gate, the runtime creates a task on the shared task board and waits for the person — same pause, same persisted state, same resumption. The only difference is how long the wait takes. There is no privileged code path for humans and no separate “approval subsystem”; humans and Agents are symmetric Actors dispatched through the same runtime.
Section 5 of the platform architecture states it directly: the runtime “treats waiting on a human like waiting on a tool return — same primitives, different latency.” That single design decision is what turns oversight from a process you remember to run into a property of the system. The work physically cannot continue past the gate until a human acts, because the run is paused there, with its state durable enough to survive a restart.
The HITL flow, step by step
- Gate triggered — the Harness reaches a step requiring a human.
- Assignee resolution — the runtime determines which human or human role the step belongs to.
- Task creation — a task appears on the workspace task board, the surface Actors share.
- Notification dispatch — the assignee is notified.
- Pause and persist — the run pauses and its state is saved; nothing burns budget while it waits, and the run survives a restart.
- Human acts — the person approves, blocks, edits, or supplies the needed input.
- Resumption — the runtime resumes the Harness from exactly where it paused — no lost context, no re-run from the top.
Why is a bolt-on approval queue not good enough?
Because a bolt-on lives outside the work, and anything outside the work can be skipped. A webhook can be muted, a dashboard can go unwatched, a “please review” message can scroll past — and the agent, if its oversight is merely a request in its prompt, can proceed anyway. The failure mode is silent: the review didn’t fail, it simply never happened, and you find out afterwards.
A runtime gate cannot be silently skipped, because it is coded enforcement, not a polite request to the model. This is the same two-layer guarantee that backs all of ReBAC governance: governance lives in code, flexibility lives in prose, and code wins. If a manifest’s prose tries to route around a required HITL gate, the runtime enforces the gate regardless. Whether a step requires a human is decided by the policy set the Harness runs under — a versioned governance envelope — not by a per-run judgement the model makes about itself. That is the line between “we have a review process” and “review is structurally enforced.”
Citable answer — Why is a runtime HITL gate better than an approval queue? A bolt-on approval queue lives outside the work and can be muted, missed, or bypassed by the agent’s own reasoning. A runtime gate is coded enforcement: the run pauses and persists at the gate and cannot continue until a human acts, and prose cannot route around it because code wins. Oversight becomes structural rather than a side-channel.
What does this unlock that a workaround can’t?
Three things, each of which a bolt-on cannot promise. First, durability — because the run pauses and persists, a Harness can wait hours or days for a human without consuming budget and without losing context, then resume exactly where it stopped. A scheduled overnight job that needs a sign-off at 9 a.m. just waits. Second, a real veto — a human at a gate can block a step outright, and the work cannot proceed past the block. That is meaningfully different from an “FYI” notification the agent ignores. Third, auditability — because the gate, the pause, and the resumption all run through the platform, the human decision is part of the same provenance record as everything else, not a screenshot in someone’s inbox.
This is why HITL is a first-class concern for two different buyers at once. For an operations lead, it is the thing that lets you ship automation without giving up the final say on the steps that carry risk — write the goal, keep control, ship without the engineering backlog. For a security and compliance leader, an unattended high-stakes action is a non-starter, and “the runtime physically pauses for a human, under a versioned policy, with provenance” is the kind of claim that survives a procurement review. The same primitive serves both, because it is structural rather than cosmetic.
| Bolt-on approval queue | First-class runtime primitive (Oraclous) | |
|---|---|---|
| Where oversight lives | Outside the run (webhook, Slack, dashboard) | Inside the run, as a step |
| Can the agent proceed without it? | Often — it’s a request, not a gate | No — the run is paused at the gate |
| While waiting | Agent moved on; state may be lost | Run paused, state persisted, no budget burned |
| Can a human block? | Sometimes, after the fact | Yes — a real veto, before the step runs |
| Enforcement | Trust the prompt / the process | Coded; prose can’t route around it (code wins) |
| In the audit trail | A side artefact, if at all | Same provenance record as the rest of the work |
Where Oraclous fits
Human-in-the-loop is one of the platform’s named runtime behaviours, and it sits in the governance triangle alongside ReBAC governance and metering — the three places where the platform’s coded enforcement meets the work. It depends on the deeper idea that humans and Agents are symmetric Actors: if humans were a special case, waiting on one couldn’t be the same primitive as waiting on a tool. And it is an instance of platform-as-code — the gate is governance in code, the work around it is behaviour in prose, and code wins.
See the human-in-the-loop capability page for the flow in product context, the actor definition for the symmetry it rests on, and the operations and regulated & security solutions for how it lands per persona.
Frequently asked questions
Q: Is human-in-the-loop a workaround or built in? A: Built in. In Oraclous, HITL is a first-class runtime primitive — the Harness Runtime treats waiting on a human like waiting on a tool return, pausing and persisting the run at the gate until the person acts, then resuming. It is not a webhook or dashboard bolted on beside the work; it is a step in the same flow the Agents run in.
Q: Can a human block an agent step? A: Yes. At a HITL gate the human can let the step proceed or block it outright, and the work cannot continue past a block without human action. The gate is coded enforcement, so even if a manifest’s prose tries to skip it, the runtime enforces the gate regardless — code wins over prose.
Q: What happens to the run while it waits for a human? A: It pauses and its state is persisted. Nothing consumes budget while it waits, and because the state is durable the run survives a restart. When the human acts, the runtime resumes the Harness from exactly where it paused — no lost context and no re-run from the top.
Q: Who decides where a human gate is required? A: The policy set the Harness runs under, together with the Harness’s orchestration. Policy sets are versioned governance envelopes that anchor where mandatory gates apply, and the runtime enforces them in code. So whether a step needs a human is governance, not a per-run judgement the model makes on its own.
Q: How is this different from an approval queue in other agent tools? A: An approval queue is typically a side-channel — a notification outside the run that the agent can proceed without. Oraclous’s gate is inside the run: the run pauses and persists there and cannot continue until a human acts, with the decision recorded in the same provenance trail. Oversight is structural, not a process to remember.