Key takeaways
- Human-in-the-loop (HITL) pauses selected actions for review before execution.
- Human-on-the-loop (HOTL) keeps human supervision around a more autonomous process.
- Put a human gate before actions that are hard or impossible to undo.
Human in the loop vs human on the loop at a glance
The useful comparison is not how much human involvement a workflow appears to have. It is where control sits for each consequential action. Human-in-the-loop includes direct involvement in decisions, approvals, outputs, feedback, or intervention. Human-on-the-loop places supervision or review around an AI-controlled process with more autonomy.
| Criterion | HITL | HOTL | Harness control |
|---|---|---|---|
| Execution authority | A person reviews selected decisions or actions | The process operates with more autonomy under human oversight | Separate the tools an agent can see from the actions that need approval |
| Intervention timing | Pause before the selected action executes | Supervise execution or review its results | Partition discovery, approval, and invocation |
| Undo cost | Gate the hard-to-undo or impossible-to-undo step | Allow closer supervision where actions are more reversible | Treat undo cost as a design constraint |
| Observable events | Record the request, decision, and approval | Inspect decisions, tool choices, parameters, context, and intermediate steps | Capture logging, tracing, and audit events |
| Recovery | Resume an expected approval pause from the same state | Track and respond to incidents found through supervision | Preserve state and support communication, tracking, response, recovery, and documentation |
Compare control placement one action at a time
Start with an action, not a label for the whole workflow. The first question is whether the agent can discover a tool. The second is whether it may invoke that tool without a person approving the particular call. In OpenAI's execution model, tool visibility and approval checks are separate decisions. An agent can therefore know that a tool exists without receiving unconditional authority to use it.
The execution path can make that distinction concrete. Discovery, approval partitioning, and invocation can be separate phases. Discovery identifies the requested work. Approval partitioning separates calls that can proceed from calls that must wait. Invocation executes only the work whose control condition has been satisfied.
This separation narrows the approval decision to a pending invocation. Tool discovery remains separate from approval partitioning, and invocation follows as its own execution phase.
That sequence gives builders a precise place to compare human-in-the-loop vs human-on-the-loop. HITL inserts a review before a selected invocation. HOTL permits more autonomous invocation while a person supervises the process or reviews results. Neither choice has to govern every action in the run.
Undo cost decides where a pre-action gate belongs. Treat it as a design constraint, then locate each action on the spectrum. A human gate should precede a step on the hard-to-undo or impossible-to-undo side. This keeps the decision tied to the side effect that creates the consequence, instead of applying one broad autonomy setting to unrelated work.
Why does HITL belong before some actions?
HITL belongs before an action when waiting for approval is preferable to dealing with that action after execution. Approvals can pause risky side effects, so the system can prepare a proposed call and stop before it crosses the boundary.
External side effects make the boundary easy to see. Emails, webhooks, and payments cannot be made reversible and should be gated. Once the agent sends the email, triggers the webhook, or makes the payment, restoring internal state does not reverse the external event. The useful checkpoint is therefore before invocation, while the proposed action is still only a proposal.
Charging a card, deleting data, and changing production state are concrete approval candidates. A high-risk action gate holds an irreversible or sensitive step until a reviewer explicitly approves what happens next. The pause is intentional. It is part of the execution design, not an unexpected failure.
This is also why access and approval cannot collapse into one permission. A tool may be available because the agent needs it for some calls. The action still may need review when its specific invocation carries a hard-to-reverse side effect. The gate applies at that action boundary.
Human review has an operational cost: the flagged action remains paused until a reviewer approves it. That cost is real, but so is the difference between reviewing a proposed charge and trying to respond after the charge has already happened. The harness makes that tradeoff explicit at the point of execution.
Autonomous execution still needs runtime controls
HOTL does not end at granting an agent permission and watching its final output. An agent can stay inside its authority envelope and still cause a production incident by executing allowed operations too quickly. Authority answers whether a call is allowed. It does not control the tempo of repeated allowed calls.
Consider a tight loop of allowed file deletions or a burst of allowed API calls. Each individual call can fit the authority policy while the series creates the incident. Operational tempo can be constrained with per-tool limits, per-tier defaults, and a global limit across all tool calls. Per-tool control limits one operation. A tier default applies a shared posture to a class of tools. The global limit bounds activity across the run.
Supervision also needs a view of the trajectory, not only the final response. An agent trace can contain decisions, tool choices, generated parameters, retrieved context, and intermediate steps. Automated final-answer scoring may miss those events. A plausible result does not show which tools ran, which parameters they received, or what context shaped the path.
Lifecycle callbacks can capture logging, tracing, and audit events. Guardrails can check requests and outputs. Together, these mechanisms give HOTL supervision something concrete to inspect: what the agent requested, how the harness handled the request, and what the run produced.
The measurement plan should follow the risk model. Select approaches and metrics by starting with the most significant identified risks, and document characteristics that cannot be measured. Rate controls constrain operational tempo. Traces record tool choices and parameters. Guardrails can check requests and outputs. These controls expose different parts of an autonomous run without reducing supervision to the final answer.
Incident and error processes should include communication, tracking, response, recovery, and documentation. Those responsibilities remain part of the operating design around an AI system.
Where each pattern fits in practice
Take documentation drafting. The agent can draft text autonomously when the work has no sensitive data and no direct customer impact. The draft remains available for review, while the system avoids inserting an approval pause into every generation step. This is a HOTL-shaped placement: more autonomous execution with a person able to supervise or review the result.
Reversibility can move the gate without removing control. For agent-generated content, comments are more reversible than body edits. Git branches, draft pull requests, and checkpoints are also reversible workflow primitives. They preserve a state or proposed change that can be inspected before it becomes a harder-to-undo effect.
Production deployment sits on the other side of the decision. File deletion, database migration, and production deployment can be placed behind explicit reviewer approval. The agent may discover the relevant tool and prepare the proposed operation, but the invocation waits. That is an action-level HITL boundary inside a workflow that may otherwise run autonomously.
This mixed placement is not a claim that one pattern always performs better. It is a way to apply the same test consistently. Ask who may execute the action, whether review must happen before it, how costly it is to undo, what events will be recorded, and how the system will recover. The answers may differ between drafting a document and deploying to production, even when one agent handles both.
How should a paused HITL run resume?
A paused HITL run should continue from saved state and execute unresolved or newly approved work. It should not rediscover the same work or rerun calls that already completed. A human approval request is an expected pause, so the resume path belongs in the normal design of the loop.
The state record needs to distinguish completed calls, unresolved calls, and resolved approval decisions. Once an approval state is resolved, it should remain authoritative. A dynamic approval checker should not recompute that decision during resume. Otherwise, a call that a person already approved or rejected could return to an unresolved state.
Durability applies to the decision as well as the workflow state. The checkpoint preserves the run. The resolved approval remains authoritative. On resume, unresolved or newly approved work can execute without rerunning completed calls.
LangGraph offers one concrete implementation. An interrupt can save workflow state under a stable thread_id. Invoking the workflow with the same thread_id and a Command(resume=...) payload restores that state and continues from the interrupt point. The implementation detail is framework-specific, but the control property is clear: the pause has durable identity, and the resume operation points back to it.
The execution lifecycle needs the same discipline after state restoration. Unresolved or newly approved work can execute. Completed calls remain completed. This prevents an approval pause from duplicating a side effect that occurred earlier in the run.
Checkpointing also supports failure recovery outside the approval path. A checkpointed runtime can restart a failed agent or executor node without rerunning completed steps. A pause and an incident are different events, but both benefit from durable state that identifies completed work.
This is the part of HITL that a simple approval dialog misses. The interface can collect a yes or no, but the harness must preserve the run, bind that decision to the pending action, and resume the correct work. Our approval-gate guide goes deeper on that durable boundary.
Does the 30% rule decide the human and AI split?
No. The 30% rule in AI is a symbolic mental model, not a law or standard. It assigns repetitive, high-volume, rule-based work to AI. It assigns strategy, creativity, ethical judgment, and relationship management to humans. The percentage changes with context.
That makes the rule a rough prompt for discussing work allocation, not a formula for placing control in an agent loop. A workload-wide percentage cannot tell you whether one proposed payment should pause, whether an allowed tool is running too quickly, or whether a completed call should run again after resume. Those are action-level harness decisions.
The more useful rollout pattern is incremental. Agent capabilities can start small, be validated with real users, and expand over time. That lets the authority envelope, approval points, observability, and recovery path grow with the actual work. It does not require a fixed human share before the system has run.
The initial capability can be narrow. Real users can validate it before the system expands. The symbolic percentage remains adaptable to context.
The technical foundation still matters. Reliable agents pair capable models with well-defined tools and clear, structured instructions. Agents can execute workflows end to end, including work involving complex decisions, unstructured data, or brittle rule-based systems. As the execution path expands, the harness must keep capability separate from permission. A model may be capable of proposing a call without having authority to invoke it autonomously.
Use the 30% idea only at the level it supports: a contextual way to discuss which kinds of work lean toward automation and which retain human judgment. For control placement, inspect the real actions. Put approval before the consequential side effect, supervision around autonomous execution, and recovery behind both.
Continue from control placement to implementation
Once the action boundaries are clear, place them inside the actual execution path. Agent guardrails can span input filtering, tool use, and human-in-the-loop intervention. The agent-loop guide provides the larger structure for deciding where the model acts, where the harness checks the run, and where a person takes control.
For a selected pre-action boundary, use the approval-gate guide to design the pause and resume path. Record the pending action, preserve its state, bind the human decision to that action, and continue only the unresolved or newly approved work.
Start with one consequential action in a real loop. Name its authority, approval timing, undo cost, observable events, and recovery path. Then test the pause and resume behavior before widening the agent's execution authority.