Every team deploying an AI agent into a real workflow eventually has to answer a deceptively simple question: does this action require a human to approve it first, or can the agent just do it? Get this wrong in one direction and the system is too slow and expensive to be worth the investment, since a human is reviewing everything anyway. Get it wrong in the other direction and the system is fast but occasionally does real, sometimes expensive, damage before anyone notices.
Requiring approval on every single agent action feels like the conservative, safe choice, and in the earliest stage of a deployment it usually is. But left in place too long, it quietly caps the value of the entire system. If a human has to review every output, the agent hasn't actually removed the bottleneck, it's just changed the shape of the work a human does, from performing the task to checking someone else's version of it. Many organizations run pilots this way indefinitely, mistaking the appearance of automation for the substance of it.
Removing approval everywhere, meanwhile, is how automation projects end up in postmortems. A single confidently-wrong decision executed automatically, an email sent to the wrong recipient, a refund issued incorrectly, a record updated with bad data, can do more reputational and financial damage than the entire pilot period was meant to save in labor cost.
The right threshold isn't a fixed policy, it's a function of two variables for any given action: the cost of an error if the agent gets it wrong, and the model's demonstrated reliability on that specific type of decision, measured against real historical outcomes, not synthetic test sets.
Actions with low error cost and high demonstrated reliability are strong candidates for full autonomy: routing an internal ticket to the wrong-but-adjacent team is a minor, easily-corrected inconvenience, not a real risk. Actions with high error cost, regardless of reliability, generally deserve a human checkpoint at least until the system has a long track record, because rare failures on expensive actions are exactly the failures organizations remember for years. Actions with low reliability, regardless of error cost, simply aren't ready for autonomy yet, and no amount of process design fixes an underperforming model.
The mistake we see most often is applying a single blanket policy, either full review or full autonomy, across an entire agent's action space, rather than setting the threshold action by action based on this cost-and-reliability logic.
Even well-calibrated autonomous actions need a clear, fast path for the cases that fall outside the model's confidence range. This means defining, in advance, what "outside confidence range" actually means numerically for each action type, not leaving it to informal judgment after something has already gone wrong. It also means making sure the human on the other end of an escalation has enough context to act quickly, since a slow, under-informed escalation path defeats much of the speed advantage the automation was built to create in the first place.
Human-in-the-loop design is often treated as a temporary training-wheels phase to be removed as soon as possible. It's better understood as a permanent, deliberately-tuned dial, one that should move toward more autonomy as reliability is proven on low-stakes actions, and stay conservative on the handful of actions where a mistake would actually hurt. Getting this calibration right, action by action, is what separates AI deployments that scale safely from the ones that eventually make headlines for the wrong reason.
.webp)