Decide which actions need approval
Approval design starts by naming which actions deserve a pause. Too many stops slow routine work and train you to approve on autopilot; too few let high-impact changes happen before you can review them.
The most reliable way to answer that isn’t a vague principle like “anything risky.” It’s a matrix built on two concrete axes: how hard the action is to undo, and how far its effects reach beyond the agent’s own workspace.
Two axes that predict risk
Reversibility. Can this be undone cleanly if it turns out to be wrong? Deleting a draft you haven’t sent is fully reversible. Sending an email is not. Booking a refundable hotel room is mostly reversible. Paying a non-refundable deposit is not.
External reach. Does this action stay inside the agent’s own workspace, or does it touch something outside: another person’s inbox, your bank account, a public website, a legal agreement? Drafting a document in a private workspace has no external reach. Publishing that same document does.
Plotting any action against these two axes gives a fast, consistent answer to whether it needs a gate. High reversibility and no external reach: let it run. Low reversibility, high external reach: always gate it. Most real actions fall clearly into one side or the other once you ask both questions directly.
A decision matrix for common actions
| Action | Reversible? | External reach? | Needs approval? |
|---|---|---|---|
| Reading email, calendar, documents | Yes | No | No |
| Researching and comparing options | Yes | No | No |
| Drafting a reply or document | Yes | No | No |
| Organizing files, tagging, sorting | Mostly | No | No, unless deleting |
| Sending an email or message | No | Yes | Yes |
| Booking travel, tables, appointments | Partially | Yes | Yes |
| Paying or entering payment details | No | Yes | Yes |
| Deleting or overwriting records | No | Sometimes | Yes |
| Publishing or posting publicly | No | Yes | Yes |
| Accepting contracts or invitations | No | Yes | Yes |
The pattern across the bottom half of this table is consistent: every action that requires approval is either hard to undo, reaches outside the workspace, or both. That’s the actual rule, not a list to memorize by category.
What a good approval request looks like
A gate is only as useful as the decision card behind it. Compare two versions of the same moment. Weak: “Send email? Y/N.” Useful: “Send 3 follow-up emails to Acme, Brackenwold Studio and Thornquist Ventures? Drafts are written in your tone, referencing their open invoices from last month. Nothing has been sent yet.” The second version gives you what will happen, why, and what’s already been prepared, so you can decide in seconds without redoing the agent’s work yourself.
A useful approval request should let you do one of three things without extra steps: approve it as written, edit it and then approve, or hold it. If editing means starting over, the gate is adding friction without adding much safety.
Writing your own approval rules
The default matrix above covers most cases, but real work has exceptions worth setting explicitly rather than working around each time.
You might tighten a rule beyond the default: requiring approval for any message to a specific high-stakes client, even routine ones, because the relationship is sensitive enough that you want to see every word before it goes out. You might loosen a rule for a specific, narrow, repeated case: pre-approving the same weekly invoice reminder to the same list, since you’ve reviewed the pattern enough times to trust it, while keeping approval required for anything outside that exact pattern. The key property of a good rule is that it’s specific to a task or a pattern, not a blanket toggle for an entire category, since blanket toggles are exactly what leads to either too much friction or too little safety.
What happens when you’re not there to respond
The other half of designing approvals well is deciding what happens at 2 a.m. when a gate is hit and nobody’s awake to answer it. The safe default is that nothing happens: the gated action waits, the agent moves on to whatever else it can do without that step, and the decision is waiting for you, clearly flagged, when you’re back. An agent that proceeds anyway after a timeout has quietly turned a approval gate into a formality.
Where this fits with OperatorNest
OperatorNest applies this matrix by default: approvals are required before anything that sends, pays, books, deletes or publishes, presented as a specific decision card, and you can tighten or loosen rules per task. Nothing is sent or spent while a decision waits. The default matrix gives you a starting point; set tighter or looser rules for each task to match your risk tolerance. See what an approval gate is for the underlying mechanism this post builds on, or use the AI agent approval policy builder to write down those rules.