"Human in the loop" has become a reassurance rather than a description. It gets said in vendor decks and governance reviews to mean don't worry, a person is involved, and almost nobody follows it with the sentence that would make it useful: involved how, at which moment, deciding what.
There are three distinct postures hiding inside that phrase. They imply different work, different risks, and different failures. Teams that have not named which one they are running are usually running the weakest of the three while believing they have the strongest.
In the loop
The agent cannot act. A person approves each output before it goes anywhere.
The human is a gate. Work stops at them and waits. Nothing reaches a customer, a campaign, or a colleague without someone looking at it first.
This is the strongest guarantee and the most expensive one. It scales linearly with output, which is the problem: the whole point of adding agents was to produce more, and in-the-loop review means a person has to read everything that gets produced. Teams start here, correctly, and then discover they have moved the bottleneck rather than removed it.
On the loop
The agent acts. A person monitors and can intervene.
The human is a supervisor watching a stream. Output ships without individual approval, and the person's job is to notice when something is wrong and stop it.
This scales, which is why teams move here. It also contains a specific and well-documented failure: a person watching a long run of good output stops seeing. Attention degrades precisely because the system is working. By the time the bad output arrives, the supervisor has been trained by hundreds of fine ones not to look closely.
So "someone is monitoring it" is a weaker assurance than it sounds. Monitoring is a real job with real requirements, and treating it as a passive safety net is how on-the-loop quietly becomes no-loop.
In command
A person decides, in advance, what the agent may decide. The agent acts without asking only inside those bounds, and escalates everything else.
Here is the part most teams miss: this is not a third point on a spectrum.
In the loop and on the loop describe when a human touches the work. In command describes who set the boundaries before any work happened. They are different questions, and you answer both.
That means the combinations matter more than the labels:
- On the loop and in command is a well-run agent. The boundaries were set deliberately, the agent operates inside them, a person watches.
- In the loop but not in command is more common than anyone admits. A person approves every output, but no one ever defined what good looks like, what is out of scope, or what should have been escalated. Approval without a standard is rubber-stamping with extra steps, and it carries the cost of in-the-loop review with none of the protection.
You answer both questions, not one. On the loop and in command is a well-run agent. In the loop and not in command is approval without a standard.
What being in command actually requires
It is a document, not a disposition. For each decision an agent touches, someone has written down three things:
What the agent decides alone. Specifically, with examples. "Tone adjustments within the brand voice guide" is a decision right. "Minor stuff" is not.
What it escalates. Also specifically, and framed as triggers rather than judgment calls. An agent cannot reliably notice that something feels off, but it can reliably notice that a claim includes a number, or that a draft names a competitor.
Who it escalates to, by name. Not a team. A person who is answerable for the call.
Writing that down is most of the work, and it tends to surface that nobody had actually decided. That is the useful part. The map does not create the ambiguity, it reveals it.
Orchestration is not autonomy
The reason this vocabulary matters is that the two get conflated, usually by people selling something.
An orchestrated system looks autonomous from the outside. Work arrives, work gets done, nobody appears to be steering. The difference is invisible until something goes wrong: in an orchestrated system a person set the bounds and the agent escalated when it hit one, and in an autonomous system the agent decided for itself what was in bounds.
Agents act without asking only within decision rights a human has set. Everything else escalates. That is the line, and a team can be on either side of it while producing identical output right up until the day it matters.
The question worth asking this week
Pick one workflow where an agent produces something that reaches a person outside your team. Then ask, in this order:
When does a human touch this? Before it ships, after it ships, or not at all.
Who decided what this agent is allowed to decide, and where is that written?
Most teams can answer the first and not the second. That gap is not a tooling problem and it does not get better as the agents improve. It is the work.
The unit all of this sits inside is the pod: what a marketing agent pod is, and the four properties that separate one from a pile of prompts.