Every useful agent eventually wants to do something you cannot undo. Send the email. Issue the refund. Close the ticket. Update the record the finance team reconciles against.
The question of which of those it may do on its own is the most important design decision in an agent project, and it is routinely left to a default. It should not be. It is a business decision, it belongs to the people who carry the consequences, and it is cheap to make properly before the build and expensive to revisit afterwards.
Sort actions by what it costs to be wrong
Not by how likely the agent is to be wrong. By what happens when it is.
Reversible and private. Reading a record, running a search, drafting something nobody has seen. Getting these wrong costs a retry. Agents should do these freely and without ceremony — gating them adds friction and buys nothing.
Reversible but visible. Updating a status, assigning a ticket, adding a note. Wrong is annoying and fixable, but someone saw it. These usually run unattended with a good trace, so a mistake can be found and reversed quickly.
Irreversible, or it reaches a customer. Money moves, an email sends, a record is deleted, a contract state changes. Wrong here costs trust or cash and cannot be taken back. These queue for a person.
The third category is smaller than teams expect. That is the useful part of the exercise: most of the work an agent does is in the first two bands, and once you have sorted them you usually find the agent can run most of the workflow alone while a human approves a handful of steps a day.
Approval has to be cheaper than doing the work
This is where the design usually fails. If approving an agent’s action takes a person as long as doing the task themselves, they will stop approving and start doing — and you have bought an expensive way to add a step.
An approval should carry, in one screen: what the agent wants to do, in plain language; why — the retrieved context and the reasoning; what happens if it is approved; and a one-click yes or no. If the reviewer has to open another system to decide, the boundary is in the wrong place or the tool is returning too little.
Batch where the work is homogeneous. Twenty refunds under a threshold reviewed together beats twenty separate interruptions.
Design for the queue nobody drains
Approval queues rot. Someone is on leave, a busy week happens, and two hundred items are waiting.
Decide in advance what expiry means for each action type. Some should fail closed — the refund is simply not issued, and the customer-facing consequence is handled another way. Some should escalate to a second approver. Some genuinely can auto-approve after a delay, but only in the reversible-but-visible band, never in the third.
Say it out loud during design. A queue with no expiry policy is an outage waiting for a holiday.
Thresholds are the useful middle ground
Much of the time the answer is not “may the agent do this” but “up to what size”. Refunds under a limit run unattended; above it, a person. Emails to existing contacts send; to new contacts, approval. This gets you most of the automation value while keeping the exposure bounded, and it gives you a dial to turn as confidence grows rather than a switch to flip.
Start the threshold lower than feels necessary. Raising it after a month of clean traces is an easy conversation. Lowering it after an incident is a different one.
The boundary is a record, not a setting
Write it down, in the plainest language the business uses, and keep it beside the code:
The agent may update ticket status, assign owners and add internal notes without approval. It may draft customer replies but not send them. Refunds up to ₹5,000 run unattended when the order is under 30 days old; anything else queues for the support lead. Nothing is deleted by the agent, ever.
That paragraph is worth more than any amount of prompt engineering. It tells the build team what to enforce in the tool layer rather than in the prompt — because a boundary enforced by instructions is a suggestion, and a boundary enforced by scoped credentials and a queue is a boundary.
It also gives you something to hand an auditor that is not a transcript.
One test before you ship
Take the single worst action your agent is permitted to take alone. Assume it does it, wrongly, at the least convenient moment, to your largest customer.
If the answer is “we would reverse it and apologise”, the boundary is in the right place. If the answer involves a phone call from a director, move the line.