On April 16, 2026, MIT Technology Review published a piece arguing that "humans in the loop" oversight has become an illusion. Its focus was military autonomous systems, and its argument was precise: human overseers cannot verify what the AI is actually reasoning about internally. Investment in understanding AI decision-making has been minuscule compared to investment in building more capable models, leaving operators nominally in control of systems they cannot meaningfully audit. The article focused on military AI, but the engineering gap it named has an enterprise analog. Even when agents operate at human-reviewable speeds, the same failure mode appears in a different form: a human who is technically "in the loop" but reviewing a decision with incomplete context, under workflow pressure, and without visibility into why the agent arrived at its output isn't actually providing oversight. They're providing the appearance of it.
The response from the practitioner community wasn't to argue against the critique. It was to ask a sharper question: are we even using the right oversight model?
The answer, for most production teams, is no. Not because they chose the wrong architecture in theory, but because they conflated two distinct concepts — human-in-the-loop (HITL) and human-on-the-loop (HOTL) — and applied one of them uniformly across everything their agent does.
What "Human-in-the-Loop" Actually Means
Human-in-the-loop means the agent pauses. Before executing a defined action, the agent suspends its workflow, surfaces a decision request, and waits. A human must explicitly approve, reject, or redirect before execution continues.
This is not monitoring. It is a blocking gate. The agent cannot proceed without a human response.
In LangGraph — the dominant technical substrate for production agentic workflows in 2026 — HITL is implemented via the interrupt() function, which pauses graph execution at a defined node, persists state to a checkpointer, and resumes only when a human response is received. The agent's work is preserved. Nothing is lost. But nothing moves forward either.
HITL is the right model for a narrow category of actions: those where the cost of a wrong autonomous decision materially outweighs the cost of delay. Financial disbursements above a threshold. Legal agreements. Modifications to production infrastructure. Communications sent on behalf of an executive. Actions that are irreversible, regulated, or high-consequence.
The governance plane perspective matters here: HITL is not a property of an agent's architecture in general — it is a property of specific action types within that architecture. The mistake is treating it as a global setting.
What "Human-on-the-Loop" Actually Means
Human-on-the-loop is architecturally different. The agent executes. A human observes the output stream, monitors for anomalies, and intervenes after the fact when something looks wrong. There is no blocking gate. There is no pause.
HOTL is appropriate for a much larger category of actions: those where the cost of delay exceeds the cost of occasional reversible errors. Read operations. Summarizations. Draft generation. Search queries. Low-stakes data retrieval. In a HOTL model, a human operator may be overseeing dozens or hundreds of concurrent agent tasks simultaneously via dashboards and alert thresholds, rather than approving each one individually. The human role is supervisory, not transactional.
What Arize's observability tooling covers well is HOTL: traces, evaluations, annotation workflows for reviewing outputs after the fact. LangSmith's evaluation framework is fundamentally a HOTL instrument — useful for the monitoring layer, designed for the case where the agent already ran. What neither addresses is the upstream question: which actions should be blocked for approval before execution, and who decides that boundary? That decision is being made in agent code, which is the wrong place for it.
The Real Problem: The Oversight Model Lives in the Wrong Place
The standard approach in 2026 is to encode the oversight model inside agent code. A developer writes the approval logic into the agent itself: if action.type == "payment": interrupt(). This works for the specific case the developer anticipated. It breaks for everything they didn't.
Three failure modes emerge.
Coverage drift. As agent capabilities expand, new action types appear that the original developer didn't anticipate. The interrupt logic doesn't cover them. The agent acts autonomously on actions that should have been gated. Nobody notices until something goes wrong.
Uniformity errors. Developers default to one extreme or the other: interrupt on everything, or interrupt on nothing. The first destroys the agent's value — blocking every action creates so much friction that it undermines the whole point of having an autonomous agent. The second creates governance theater: humans nominally in the loop on actions they lack the context or visibility to evaluate meaningfully, producing exactly the nominal-but-not-real oversight that MIT Technology Review flagged in April 2026.
No audit trail. When the override rule lives in code, there's no systematic record of which actions triggered approvals, what the human decision was, how long review took, or whether patterns are developing. Compliance teams asking "how are you ensuring human oversight for regulated actions?" have no clean answer.
A tiered approval policy — enforced at the governance layer, not inside agent code — solves all three problems. The policy defines action categories and their required oversight model. The governance layer intercepts agent actions before execution and routes them accordingly. Agent code doesn't need to know; it just runs. The oversight model is maintained centrally, versioned, and auditable.
This is the architectural distinction that most observability-first tooling misses. Observability tells you what the agent did. A governance layer with enforcement authority decides what the agent is allowed to do — and how much human involvement that requires.
The Risk-Tier Framework That Actually Scales
The taxonomy that holds up across enterprise deployments divides agent actions into three tiers:
Tier 1 — Free run. Read operations, internal summarization, draft generation with no external effect. No human intervention required. Logging for audit trail is sufficient.
Tier 2 — Monitor and flag. Actions with external effect that are reversible: sending draft emails, updating non-critical records, making API calls with low blast radius. HOTL applies: the agent acts, a human reviews the output stream and gets alerted on anomalies. The governance layer captures the full execution trace — action, inputs, outputs, timing — and surfaces it for supervisory review without blocking the workflow.
Tier 3 — Block for approval. Irreversible or high-stakes actions: financial transactions above threshold, external communications sent on behalf of the organization, modifications to production systems, actions with regulatory implications. HITL applies: the agent pauses, the approval request routes to the designated human, and execution resumes only on explicit sign-off. The governance layer records the approval decision and the reviewer.
The critical point: this taxonomy is not encoded per-agent. It is a fleet-wide policy. Every agent in the system is subject to the same tier rules. When a new agent adds a new action type, the policy classification governs it by default — the developer doesn't need to think about it.
How Waxell Handles This
Waxell's approval policies operate at the governance plane, outside agent code. An operator defines which action categories require blocking approval (Tier 3), which require passive monitoring (Tier 2), and which can execute freely (Tier 1). The agent implementation doesn't change; the policy changes.
For blocking actions, Waxell intercepts the execution, routes it to the designated approver, and holds the agent in a suspended state until a decision is recorded. For monitored actions, Waxell captures the full execution trace and surfaces anomalies for human review without blocking the workflow.
The result is a tiered oversight model maintained externally to agents, applied consistently across every agent in a fleet, and backed by an approval audit trail that compliance teams can use. The distinction between HITL and HOTL is a policy configuration — not a coding decision embedded in an individual agent that may or may not survive the next refactor.
For enterprise deployments where multiple agent teams share infrastructure, this matters significantly. Without centralized governance of oversight tiers, each team makes its own decision. Some over-gate. Some under-gate. None are consistent. When an auditor asks how human oversight works across the fleet, the answer without centralized governance is: it depends on who wrote each agent and when.
Waxell's assurance model makes the oversight tier explicit, enforceable, and auditable — not a promise embedded in code that may drift as agents evolve.
FAQ
What is the difference between human-in-the-loop and human-on-the-loop?
Human-in-the-loop (HITL) requires a human to approve an action before it executes — the agent pauses and waits for a decision. Human-on-the-loop (HOTL) allows the agent to act autonomously while a human monitors outputs and can intervene after the fact. HITL is appropriate for high-consequence, irreversible, or regulated actions. HOTL is appropriate for faster-moving, lower-risk work where delay costs more than the occasional reversible error.
Is human-in-the-loop always better than human-on-the-loop?
No. Applied uniformly, HITL destroys the value of agentic systems by turning every autonomous action into a bottleneck. The right model depends on the action category. The failure mode to avoid is HITL theater — a human who nominally approves but lacks the context or visibility to evaluate meaningfully, producing the illusion of oversight rather than the substance of it, as MIT Technology Review argued in April 2026.
Where should the HITL/HOTL boundary live — in agent code or in a policy layer?
The governance layer, not agent code. When oversight rules live in code, they're subject to coverage drift, inconsistency across agents, and poor auditability. A centralized policy layer enforces oversight tiers uniformly across all agents, catches new action types by default, and produces an audit record of every human decision.
What actions always require human-in-the-loop?
A reliable baseline: financial disbursements, external communications sent on behalf of the organization, modifications to production infrastructure, actions with regulatory implications (GDPR data deletion, HIPAA-regulated records), and any irreversible action above a defined risk threshold. The exact list should be an explicit policy configuration — not implicit in a single developer's judgment.
How do I know if my current HITL implementation is adequate for compliance?
The test is whether you can produce, for any regulated agent action, a timestamped record showing what action was proposed, who reviewed it, what decision was made, and how long review took. If that record requires manual log extraction, it's insufficient. If the oversight rules live only in agent code without a policy manifest, compliance cannot be demonstrated consistently across the fleet.
What does "human-on-the-loop" look like in production?
An operator monitors a live dashboard of agent activity. Alert thresholds fire when actions fall outside expected parameters — unusual data access, unexpected API calls, outputs that don't match quality baselines. The human doesn't review every action but reviews flagged ones in near-real-time and can halt execution if needed. The governance layer tracks what was flagged, what was reviewed, and what was bypassed, creating a supervisory audit record distinct from a blocking approval record.
Sources
- "Why having 'humans in the loop' in an AI war is an illusion" — MIT Technology Review, April 16, 2026. Primary hook. Article argues that HITL is illusory because human overseers cannot verify what AI systems are actually reasoning about internally. Focused on military systems; the post applies the enterprise analog.
-
"Human-in-the-Loop AI Agents in LangGraph: The 2026 Production-Ready Approach" — GrowwStacks, 2026. LangGraph
interrupt()function description; approval workflow friction in production agents. - "From Human-in-the-Loop to Human-on-the-Loop: Evolving AI Agent Autonomy" — ByteBridge/Medium, 2026. HITL/HOTL architectural distinction.
- "The Loop Paradox" — Savneet Singh/Medium, March 2026. Extended taxonomy of human oversight positions across agent systems.
- "Human-in-the-Loop: A 2026 Guide to AI Oversight" — Strata.io, 2026. HITL definition: qualified person with timely context, authority to intervene, defensible rationale.
- "Production AI Playbook: Human Oversight" — n8n Blog, 2026. Risk-tiered framework: low/medium/high-risk action categories.
- "AI: Where in the Loop Should Humans Go?" — Hacker News, 2025. Community discussion on oversight spectrum and friction vs. governance tradeoff.
Top comments (0)