Where human approval belongs—and where it only creates busywork

Approval is for consequences, not discomfort

Requiring approval for every step turns a capable agent into a slow web form: it can look, but it must ask before doing anything at all. Requiring approval for nothing treats every mistake as equally cheap to undo. Neither is a policy—both are just a default nobody chose.

The useful principle sits between them. Place a gate at the last moment before an action becomes hard to reverse, and nowhere else. Reading, sorting, and drafting can run freely, because a bad draft costs a glance to fix. Sending, paying, and deleting deserve a pause, because the result leaves your control the instant it happens.

How to judge it: if a reviewer could undo the action in under a minute with no outside consequence, it probably does not need a gate.

Use the consequence test

When you are unsure whether an action needs approval, ask one question: after this runs, what has changed outside the dashboard, and how hard is it to take back? Require approval before any action that:

• Moves money—payments, refunds, credits, or changes to what a customer will be charged.
• Reaches a person—an email, message, or reply sent under your name.
• Publishes in public—anything customers or search engines can see.
• Deletes or overwrites—records that are slow or impossible to rebuild.
• Changes access—permissions, connections, or shared settings.
• Creates a commitment—a promise, contract term, or legal obligation.

Everything else—reading, searching, summarizing, drafting, tagging—usually runs without a gate. Those actions stay inside the safe space of a draft, where a mistake is visible and cheap to fix.

Compare three control levels

Most work fits one of three control levels. The skill is matching the level to the consequence, instead of applying one setting everywhere.

• Automatic—reversible, low-impact work the agent does and logs. Example: sorting new support messages by topic. Get one wrong and you re-tag it in seconds.
• Review after—the agent acts, then shows you what it did so you can correct it. Example: drafting replies into a folder for you to edit before sending. Speed matters and every step is easy to undo.
• Approve before—the agent prepares the action but waits for a yes. Example: sending those replies, issuing a refund, or deleting a list. The consequence is external or permanent.

The trade-off is real: every “approve before” gate buys safety with your time. Spend it only where an undo button does not exist.

Write an approval people can judge

A gate is only as good as the request it sends. “Approve task?” forces the reviewer to open another system to learn what they are agreeing to—so they either stop to investigate or, more often, approve blind. A good request carries its own context: the exact action, the target, the reason, and the consequence.

“Send this refund confirmation to Asha Patel for ₹2,400? Reason: duplicate charge on order #4821. This emails the customer immediately.”

That version can be answered correctly from a phone in ten seconds. The reviewer sees who is affected, why, and what becomes true the moment they tap yes.

Measure approval quality

A gate that is never rejected is not proof of safety—it is usually proof the gate is in the wrong place. Watch two numbers over a month:

• Rejection rate near zero: reviewers are rubber-stamping. Move the gate to where a real decision exists, or remove it and switch that work to “review after.”
• Long waits on safe work: a gate is blocking things that were never risky. Narrow it so approvals are reserved for consequences, not routine steps.

Read the rejections themselves, not just the count. The reasons people give for saying no are the clearest map of where your real boundaries are.