Your autonomous AI agent books meetings, sends emails, and updates CRM entries. One hallucinated action accidentally emails the wrong customer. How do you add approval, rollback, and safety layers to autonomous AI agents?

What you need to know

Classify actions, not the agent

"Is this action important?" is too vague. Two concrete questions work better: can it be undone, and how much can it affect?

This table lives in code. The model can ask for an action; it cannot decide whether that action needs permission.

1POLICY = {2    "crm.update_field": "auto",3    "crm.bulk_update":  "auto_with_undo",4    "calendar.book":    "approve",5    "email.send":       "approve",6}78def execute(action, args, run):9    tier = POLICY.get(action, "approve")                    # unknown tools need approval10    if tier == "approve":11        return approvals.request(action, args, reason=run.reasoning, sources=run.sources)12    before = snapshot(action, args)13    result = TOOLS[action](**args, idempotency_key=run.step_id)14    action_log.write(run.id, action, args, before, result, undo=COMPENSATE[action])15    return result

Unknown tools fall into the approval tier by default. The idempotency key stops a retry from doing the same thing twice.

If a tool has no compensating action — a sent email cannot be unsent — it belongs in the approval tier by definition.

Approval that people actually read

Show the exact payload: recipient, subject, body. Add the agent's reasoning and the sources it used. Let the reviewer edit, not only approve or reject, and expire requests nobody answers.

The fix for this incident

1. Delayed outbound queue — hold every email for 60 seconds with a visible "Undo send". Cheap, and it stops many wrong-recipient mistakes.
2. Deterministic entity resolution — before sending, look up the customer named in the task in the CRM yourself, and assert the recipient address belongs to that record. A mismatch blocks the send.
3. Blast-radius limits — maximum sends per run, per-tool rate limits, a spending cap and a kill switch.
4. Volume alerts — an agent sending 12,000 emails should trip an alarm long before it finishes.

The wrong-customer email is an entity-resolution bug. It deserves a database check, not a better prompt.

A real-life example

Scenario, numbers made up. A sales team's agent follows up on meetings. Asked to "send the revised quote to Sharma Textiles", it picks the contact for "Sharma Traders", a different customer, and emails a confidential price sheet.

The team adds three things. A recipient check compares the email's domain and contact id against the CRM account named in the task; in the first month it blocks 14 sends. A 60-second undo window catches 6 more mistakes spotted by humans. Bulk actions are capped at 50 per run. The next quarter has zero wrong-recipient emails, and approval requests fall to one in eight actions because internal CRM updates stay on auto.

Follow-up questions to expect

• "Won't approvals annoy users?" — Only irreversible actions need them. Track the override rate per action type; when humans approve almost everything unchanged for weeks, move that action to auto with undo.
• "What goes in the action log?" — Run id, tool, arguments, before-state, after-state, who approved, and the compensating action. That makes rollback and audits possible.
• "How is this different from a saga?" — It is the same idea: a sequence of steps where each step has a registered undo, so a partial failure can be rolled back step by step.