Human in the loop, on the loop, out of the loop

Every team adopting AI says it keeps “a human in the loop”. Almost none of them mean the same thing by it, and the difference decides whether the tools give you leverage or just a slower version of the work you already did.

The vocabulary isn’t new. It comes from human supervisory control — the research tradition that asked, decades before this wave, how a person should oversee a machine that acts faster than they can react, and later hardened into autonomy doctrine. It gives us three arrangements, not one.

In the loop

The system cannot act without a human decision inside each cycle. It proposes; you approve; then it proceeds. Remove the human and nothing ships.

This is where nearly everyone starts, and it is the right place to start. It is also the arrangement people mean when they say AI “didn’t really speed us up” — and they are usually right, because being in the loop caps the system at your personal throughput. Ten agents proposing changes to one approver is a queue with extra steps. You have automated the typing and kept the bottleneck.

In the loop is correct when the cost of a wrong action is high and irreversible, when you cannot yet describe what “good” means precisely enough to encode it, or when you simply don’t have the evidence to trust the system. The last one is not a weakness — it is the honest state of most teams in month one.

On the loop

The system acts on policy you wrote; you supervise and handle exceptions. Remove the human for a day and work still ships — that is the whole point, and also the whole risk.

This is where my own fleet runs. I don’t approve each change. I authored the rules the agents cannot break, the review gates every change passes, and the conditions under which something merges: panel passed, CI green, policy satisfied. What reaches me is what the system was told to escalate, plus whatever I choose to sample. I wrote about what that does to the job in supervision is the new management.

Being on the loop is not a lighter version of being in it. It is a different job with a harder entry price:

• The policy has to be written down. Not “we’re careful about database changes” — a rule an automated reviewer can enforce, with an explicit list of what blocks. Vague standards produce vague enforcement.
• You need gates that actually stop things. A review that always passes is theatre. Mine block on a fixed set of failures and the loop repeats until they clear.
• Everything has to leave a trace. Supervision without inspection is abdication. If you can’t reconstruct what happened and why, you are not on the loop — you are guessing about it.
• You have to design the exceptions. The hard question stops being “what should the system do?” and becomes “what should reach me?” Too little and you are absent; too much and you are a bottleneck holding a dashboard.

Get those four right and the throughput ceiling stops being your calendar. Get them wrong and you have built an unsupervised system with a supervisor’s job title.

Out of the loop

The system acts and no human is watching in any meaningful way. Not a mode anyone chooses on a slide — a mode teams drift into, usually by moving to “on the loop” without doing the four things above.

The tell is quiet: exceptions stop arriving. That feels like the system is running perfectly, and occasionally it is. More often nobody defined what an exception was, so nothing qualifies. The second tell is that nobody samples the trace anymore because it has always been fine.

Out of the loop is also where accountability quietly evaporates — everyone assumes someone else is reading the output.

Which one are you actually in?

Ignore what the deck says and ask three questions:

1. If every human went on holiday for a week, what would ship? Nothing → in the loop. The normal week’s work → on the loop. You don’t know → out of the loop.
2. When did something last get blocked, and by what rule? If you can’t name it, your gates are decorative.
3. What was the last exception that reached a human, and who decided it? If nothing has escalated in weeks, either your policy is extraordinary or nobody wrote one.

The move, in the right order

The mistake is treating this as a switch. It’s a sequence, and each step earns the next:

1. Work in the loop deliberately and pay attention to what you keep correcting. Your approvals are the raw material for the policy.
2. Turn the repeated corrections into rules that a reviewer — human or agent — can enforce without you in the room.
3. Move the safe classes of change on the loop first: the ones where failure is visible, cheap and reversible. Keep the irreversible ones in.
4. Instrument everything, sample the traces on purpose, and treat a week without escalations as a question rather than a result.

Notice what the sequence protects. Being on the loop doesn’t mean caring less; it means the caring is encoded once instead of performed daily. And some decisions never move — there is a list I refuse to automate, not because a model couldn’t produce an answer, but because owning the answer is the job.

The loop runs itself. Deciding what it is allowed to do is still yours.