Human-in-the-loop means an AI agent's action is blocked until a person actively approves it; human-on-the-loop means the action proceeds on its own while a person monitors what's happening and can intervene, but only after the fact if something looks wrong. The difference sounds subtle, but it changes the entire risk profile of an action. In-the-loop stops a bad decision before it takes effect. On-the-loop lets a bad decision happen and then relies on someone noticing quickly enough to limit the damage. Neither model is universally correct; the right choice depends on whether the action in question is reversible, how fast it happens, and how closely a human can realistically keep watching.
What human-in-the-loop actually requires
For in-the-loop to work, the approval step has to genuinely block execution, not just log a request and proceed anyway if nobody responds within some window. It also needs the approver to have enough context to make a real decision quickly, not just a raw log line to interpret cold. A well-designed in-the-loop gate presents the action, its impact, and relevant surrounding context clearly enough that approval isn't just a reflexive click. Badly designed ones turn into a rubber stamp, which defeats the entire point.
What human-on-the-loop actually requires
On-the-loop depends on monitoring that's fast and clear enough for a person to catch a problem while it still matters, and on the action itself being something that can be paused, reversed, or contained if a human does step in. It works well for actions that happen frequently, are individually low-impact, and would be impractical to gate one by one, but it falls apart if the underlying actions are irreversible by the time anyone notices, because there's nothing left to intervene on.
The speed and reversibility test
A useful way to decide between the two: if an action is reversible and happens slowly enough that a person could plausibly catch and undo a mistake, on-the-loop can be reasonable. If an action is irreversible, or happens too fast for a human to meaningfully react before the effect is locked in, it needs to be in-the-loop, gated before execution, not just observed after.
Where a hybrid approach makes sense
Many real systems use both, applying in-the-loop gates to the small set of high-impact, hard-to-reverse actions, and on-the-loop monitoring for the much larger volume of routine actions where blocking every single one would make the agent useless. The dividing line should be drawn deliberately, based on impact and reversibility, not by which model happened to be easier to build first.
The cost of getting the choice wrong
Applying in-the-loop everywhere creates approval fatigue, where reviewers start clicking through requests without really evaluating them, which quietly turns a real control into a fake one. Applying on-the-loop to actions that should have been gated means damage happens before anyone can respond, no matter how good the monitoring is. Both failure modes look fine in a demo and only reveal themselves once something goes wrong in production.
Documenting the classification decision
Whichever model an action ends up under, the reasoning behind that choice is worth writing down at the time the decision is made, not reconstructed later when someone questions why a specific action was only monitored rather than gated. A short record, this action is reversible within a defined window and individually low-impact, therefore on-the-loop, gives future reviewers something concrete to check against as the action's actual behavior in production becomes clearer.
Without that record, classification decisions tend to drift silently as new team members inherit a system and adjust monitoring thresholds based on intuition rather than the original reasoning. Revisiting documented classifications on a regular cadence, and updating them when an action's real-world impact turns out to be different from what was assumed at design time, keeps the oversight model matched to reality rather than to a guess made early on with limited information.
Where TELEON fits
TELEON's policy enforcement can hold an action at the tool-call boundary pending approval for actions that should be in-the-loop, and it can allow an action through while recording it in the audit trail for actions better suited to on-the-loop monitoring, giving teams the audit visibility either way. Deciding which specific actions belong in which category is a judgment call based on the action's impact and reversibility, not something a policy layer decides on its own.
A short checklist
- Classify each sensitive action as reversible or irreversible before choosing an oversight model.
- Gate irreversible, high-impact actions in-the-loop, blocking execution until approved.
- Reserve on-the-loop monitoring for actions that are reversible and individually low-impact.
- Give in-the-loop approvers enough context to make a real decision, not a bare log line.
- Build monitoring fast enough that on-the-loop intervention is actually possible before damage locks in.
- Watch for approval fatigue turning in-the-loop gates into rubber stamps.
- Revisit the classification as an action's actual impact becomes clearer in production.
Neither human-in-the-loop nor human-on-the-loop is inherently the safer choice; each is safer for a different category of action. The mistake worth avoiding is picking one model for an entire system rather than matching the model to the specific action's reversibility and speed, because a single wrong assignment, an irreversible action left on-the-loop, is exactly the kind of gap that only shows up once it's too late to matter.