Scale — Week 14
Almost every vendor pitching an AI agent will tell you it operates "with a human in the loop." It's become one of those phrases that sounds like a safeguard but functions as a placeholder — something said to reassure a buyer rather than something built into the system. The question worth asking back is simple: where, exactly, is the loop? Which actions stop and wait for a person, and which ones just happen?
If nobody can answer that specifically, there isn't a loop. There's a hope.
What breaks down without a real gate
The failure mode isn't usually a rogue agent doing something wild. It's more mundane than that. A team gives an agent broad access because narrowing it felt like extra work up front, or because the platform defaults to "ask for everything" and everyone got tired of approving routine requests, so the threshold quietly got turned down. Either way, you end up with one of two states: the agent is stopped so often it's barely useful, or it's been waved through so consistently that the approval step is theatre.
Both states get described the same way in a sales deck — "human in the loop" — because the phrase describes an intention, not a mechanism. What actually matters is the specific list: which actions can this thing take without asking, which ones need a person to confirm first, and who decided that split and on what basis.
That split is a design decision. It has to be made deliberately, action by action, before the agent is given credentials to anything.
Sorting actions by what a mistake costs
The useful way to think about this isn't "risky vs safe" in the abstract — it's reversibility and blast radius. Ask two questions of any action an agent might take: if it's wrong, can it be undone, and if it's wrong, who else does it touch?
Read-only and internally reversible actions are reasonable to leave unattended. An agent pulling data to draft a report, updating its own working notes, or querying a system to check status hasn't committed anything external. If it gets something wrong, the fix is rerunning it. This is where most of the genuine time savings live, and it's also the category most teams under-use because they're nervous about the whole system rather than nervous about this specific slice of it.
Reversible actions with external visibility sit in the middle. Sending a draft email to internal review, updating a CRM record, scheduling a calendar invite. Nothing here is catastrophic if wrong, but a customer or colleague sees the mistake before anyone catches it. This is the natural home for a confirmation step — not because the agent is untrustworthy, but because the cost of a five-second check is lower than the cost of an external party seeing a bad output.
Irreversible or high blast-radius actions need a person to actively approve before anything executes. Refunding money, deleting records, sending a message to a customer list, changing a live price. These aren't places to "trust the agent's judgement" no matter how good its track record has been so far, because the entire point of this category is that a good track record doesn't protect you from the one time it's wrong.
Most organisations we talk to haven't done this sorting exercise at all. They've made one blanket decision — usually "review everything" at the start, loosened over time as review fatigue sets in — rather than three deliberate ones. The blanket approach is where trust erodes, because the actions that actually warranted a human check get lumped in with the ones that never needed it, and eventually nobody's checking either.
Where WebMCP starts to bake this in
Most of the human-in-the-loop conversation so far has happened at the application layer — inside whatever orchestration tool or agent framework a team is using, as a setting someone configures and can just as easily misconfigure. WebMCP, as currently being proposed, moves part of that decision somewhere more durable: the interface contract between a website and the agent calling it.
The idea is that a site exposes a defined set of tools an agent can call — book this appointment, add this item to a cart, submit this form — rather than leaving the agent to infer intent from scraping and clicking through the DOM the way a person would. What's notable for this conversation is that the tool definition itself can carry metadata about how it should be called: whether it executes immediately, or whether it requires a confirmation round-trip before anything commits.
That's a meaningful shift in where the gate lives. Instead of every agent vendor deciding independently how cautious to be with your checkout flow, the site itself declares it — "adding to cart doesn't need confirmation, submitting payment does" — as part of what it exposes to any agent, from any vendor, that wants to interact with it. The approval logic travels with the interface rather than living inside whoever happens to be operating the agent that day.
It's an early spec and the tooling around it is still forming, so it's worth being honest about what it doesn't solve. It doesn't decide the sorting for you — someone at the business still has to work out which of their own actions are reversible and which aren't, the same exercise described above, just now expressed as tool metadata instead of a workflow setting. It doesn't stop an agent vendor from ignoring the confirmation flag if their implementation doesn't respect it properly. And a confirmation step is only as good as what happens on the other side of it — if the "please confirm" prompt gets rubber-stamped by a person who's stopped reading them, you're back to theatre with extra steps.
What it does do is move the default decision earlier, closer to the people who actually understand the consequences of a given action on their own platform, rather than leaving it to whichever agent happens to be calling in.
What this means for how you buy and build
If you're evaluating an AI deployment — whether you're building it or buying it from a vendor — ask for the specific list. Not "does this have human oversight," but: which actions execute without asking, which ones pause for confirmation, and who made that call and why. If the answer is vague, that's the actual gap, not a detail to fill in later.
The same exercise applies internally before you extend any existing agent's permissions. Sort your own systems by reversibility and blast radius before you decide what gets automated further. It's not a glamorous piece of work, and it won't show up in a demo. But it's the difference between a human-in-the-loop that means something and one that's just a line in a proposal.
If you're working through where those gates should sit in your own systems, get in touch — it's usually a shorter conversation than people expect.
