"Human-in-the-loop" is the answer most teams give when asked how they keep an AI agent safe. It's a reasonable instinct. It's also increasingly a description of how the product used to work, not how it works now.

The phrase assumes a human is available, present, and fast enough to review an action before it commits. That assumption held up fine when agents drafted an email a person sent themselves, or flagged a ticket for someone to triage the next morning. It does not hold up for an agent that's on a live phone call, or one that's completing tens of thousands of actions a month faster than any human review queue could keep pace with.

Look at what's actually shipping in production right now, in companies' own words:

None of these numbers describe a broken process. They describe the whole point of building an agent: it does the work faster than a person could review it. But that's precisely what makes "a human is in the loop" stop being true in any meaningful sense. If a human is nominally responsible for reviewing 97,090 actions a month, they are not reviewing them. They're rubber-stamping a system they've already decided to trust, which is a different thing wearing the same label.

High volume is one failure mode. Live voice is a sharper one, because there's no queue at all.. the decision has to happen inside the conversation, in real time, with no pause for a second opinion.

Picture a collections or customer-service call where a caller asks to move an appointment or agree to a settlement. The agent has to decide, mid-call, whether to act. There's no backlog to review tomorrow. There's no ticket sitting in a queue. The action either fires during the call or it doesn't happen at all.

This is exactly the scenario where "human-in-the-loop" quietly becomes "human nowhere near the loop", not through negligence, but because the product was built to remove the human from that path on purpose. Voice agents, computer-use agents operating under stored credentials, and backend agents wired directly into business systems all share the same property: by the time a human could plausibly review the action, the value of the agent existing at all has mostly evaporated.

The more useful question is a narrower one: does the agent complete the action without a human approving each individual instance, and is the system choosing which action to take and with what arguments, rather than following a fixed, predictable script? If both are true, you don't have a human-in-the-loop system no matter what the product page says. You have an autonomous one, and the safety question changes accordingly.

For that kind of system, treating "human-in-the-loop" as the safety answer isn't just optimistic.. it can actively work against you. When it's marketed as a permanent differentiator rather than an honest description of current limitations, it tends to mean the team hasn't yet built anything that checks actions at the speed the agent actually operates.

The alternative isn't finding a faster human. It's moving the check to the same place the action happens: the moment the agent decides to act, evaluated automatically, in the time budget the agent already operates in.

Take a real example: an agent on a call tries to reschedule an appointment for "John" to Friday at 4:30 PM. There are three matching "John" records, and the caller's identity was never verified. A threshold rule wouldn't catch this, there's no dollar amount involved. A permissions check wouldn't catch it either, the agent is allowed to reschedule appointments. The only thing that catches it is something evaluating this specific action, against the actual evidence in the conversation, before it commits.

The useful response here isn't a hard stop that ends the call. It's specific feedback the agent can act on in real time: verify the caller using date of birth or phone number, then retry. Once identity is confirmed, the same action that was correctly blocked a moment ago is correctly allowed.

This is the layer Salus operates in. Salus sits between your agents and your tools as a runtime control plane: every proposed action is checked against policy and evidence before your backend executes it, whether that agent is on a live voice call, operating a browser, or calling internal APIs directly. Actions that don't hold up are blocked, clarified, or escalated with a decision receipt attached, most actions ship untouched, and the ones that don't get specific, structured feedback instead of a dead end. In controlled testing on AgentDojo's banking environment with GPT-4o-mini, adding this kind of runtime check brought mean prompt-injection attack success down from 47.7% to 0.69% across three repetitions, without requiring a human to review a single call.

You don't need to put a check on every action your agents take to move past a human-in-the-loop model that no longer matches how the product actually runs. Start with the one action where a mistake would hurt most — the one most likely to be a live call, a high-volume queue, or a stored-credential session where no human realistically reviews each instance. Replay recent traces to see what the agent has actually been doing, write an explicit policy for that one action, and run it in shadow mode alongside production so you can see exactly what would have been caught before anything is enforced.

"Human-in-the-loop" isn't dishonest when it's true. It's just increasingly not the system most companies are actually running, and the sooner the safety model catches up to that, the fewer irreversible actions slip through in the meantime.