Approval belongs at risk thresholds, not process steps
The instinct in most enterprise agent projects is to put a human check on every step. That feels safe. It is neither safe nor useful: it slows the workflow to the speed of its busiest reviewer and, as we argue below, degrades the quality of the reviews themselves. Human approval belongs where an action crosses a risk threshold, and three questions define that threshold: what does a wrong action cost, can it be undone, and does it create legal or trust exposure outside the company?
Those questions yield a workable default rule. Actions that are cheap, reversible, and internal — drafting, classifying, retrieving, calculating — run autonomously and get logged. Actions that are expensive, irreversible, or externally visible — releasing a payment, committing to a delivery date, contacting a customer, changing a record other systems depend on — require explicit approval. The middle band runs autonomously under sampled review. Consider a procurement agent: drafting a reply to a supplier query sits in the first band; confirming a price change sits in the third. Same workflow, two different thresholds.
Approval everywhere means approval nowhere
The strongest argument against blanket approval is not speed; it is what it does to the approver. When nearly every request in the queue is fine, the reviewer learns that base rate within days. Attention shifts from evaluating each case to clearing the queue, and the click becomes a habit rather than a judgment. This is the rubber-stamping mechanism: the control still exists on the org chart, but it no longer exists in behavior — and the one request that genuinely needed scrutiny receives the same reflexive click as the hundred that did not.
The warning signs are observable in your own logs: time-per-approval collapsing toward seconds, an approval rate approaching one hundred percent, queues cleared in a batch at the end of the day. Each says the gate has become a ritual. The honest responses are to remove the gate for that action class, or to raise its quality — fewer, richer approvals that reviewers can actually think about. A control that no longer discriminates is worse than no control, because it leaves behind a record of apparent diligence that contained none.
Design the decision, not the dialog box
A yes/no prompt without context does not delegate a decision; it forwards a liability. If the approver has to reopen the source systems to verify what the agent did, the approval costs more than doing the work manually — and if they don't reopen them, they are guessing. The approval surface has to carry the decision itself: what the agent intends to do, which sources it used, the assumptions it made, a confidence signal, the expected effect of the action, and what happens if the approver rejects it.
A practical test: can a competent reviewer decide in under a minute without leaving the screen? If not, the surface is incomplete. The missing piece is usually the context in front of the reviewer, not the reviewer's diligence. And offer three outcomes, not two — approve, reject, and edit-then-approve. The edit path matters most: it keeps the workflow moving while recording exactly what the agent got wrong, which is precisely the data the next section is about.
Approval behavior is telemetry
Every approval decision is a labeled data point about your system, produced by an expert, for free, as a side effect of operating it. Rejections, edits, wait times, and recurring exceptions form the cheapest evaluation dataset the product will ever have — but only if someone reads it as a dataset rather than as a queue to be emptied.
The patterns map to causes. Rejections clustering on one action type point at a retrieval or prompt problem upstream. Edits that repeatedly touch the same field say the approval surface is missing context, or the agent is missing an input. Long queue times say the approval sits with the wrong role, or at the wrong point in the workflow. Reviewing this data on a monthly cadence turns human approval from a static safety boundary into the product's main improvement loop.
Autonomy is earned with evidence, not configured once
Thresholds set at launch encode launch-day uncertainty. Keeping them fixed forever means paying an insurance premium for a risk you have since measured. The disciplined alternative is graduated autonomy: write down, before launch, what evidence moves an action class from prior approval to sampled review — for instance, a defined operating period in which approvals-without-edits stay above an agreed bar and no incident above an agreed severity occurs.
Demotion rules matter as much as promotion rules. An incident, a model change, a new data source, or an expanded scope returns the action class to explicit approval until it re-earns its status. Written this way, autonomy changes become decisions with owners and criteria rather than quiet drift — and the production-shaped pilot becomes the place where the first graduation evidence accumulates, which is exactly what a pilot is for.
The audit trail is a product feature
Most teams treat the audit trail as a compliance chore bolted on before go-live. That reading misses what the trail actually does. A record of what the agent saw, what it decided, who approved it, and what was edited is the mechanism behind everything above: the evidence that graduates an action class, the dataset that improves the product, and the replay that turns incident analysis from archaeology into a query. It is also what lets an approver trust the system enough to stop re-checking everything it does.
So design it as a first-class feature: human-readable, queryable by action class and outcome, linked directly from the approval surface. If you can replay a decision, you can defend it, learn from it, and safely automate it.
The practical next step costs one page. For your candidate workflow, list every action the agent may take; score each for error cost, reversibility, and legal exposure; assign a launch approval level and a graduation criterion. That map forces the conversation between operations, product, and legal before any code exists — and if the actions cannot be listed, the workflow is not ready for an agent yet.