Voice Agent Rollback Actions: Undoing Bookings and Payments

A voice agent that books, charges and texts will sometimes get it wrong. The hard question is not how often. It is whether you can find every wrong record and put each one right. Most teams built forward paths only. They test the booking and the payment. Nobody built the voice agent rollback actions that sit behind them. This post gives you six reversibility classes, three undo verbs, an action ledger, a blast-radius query and a runbook.

Why undo is a design problem, not an ops task

A voice call is the front door to a workflow. The agent captures a request, calls a tool, confirms aloud and writes back to a system of record. Our write-back testing guide covers how that last step drifts from what was said. This post starts one step later. The wrong record already exists. What now?

Teams often assume undo means "restore the old state." It rarely does. Microsoft's compensating transaction pattern says it plainly: such a transaction "doesn't necessarily return the system data to its state at the start of the original operation." Other users and systems have moved on. A kitchen printer fired. A technician was dispatched. A text arrived on a phone.

So undo is a new action with its own risk. It needs the same care as the original. It needs a test, a log line and an owner. Plan undo as carefully as the forward path. You can only undo voice agent actions that you can find.

Six reversibility classes for voice agent rollback actions

Sort every tool the agent can call into one class. Undo differs sharply by class. The class decides how much review the action needs before it runs. It also decides what undo looks like afterward.

Two notes on the table. First, class 0 is not always harmless. If the agent reads a balance to the wrong caller, no tool call can reverse that. Second, a single user request often spans classes. "Book me in and text me" is class 2 plus class 4. Rate the call by its highest class.

Class 5 deserves a hard rule. The agent may prepare it, never execute it. We cover who may write what in voice agent permissions. Rollback is the other half of that discussion. Permissions limit the damage you must undo. Rollback handles what slips through.

Cancel, reverse or compensate

Engineers say "roll back" for three different moves. These are the three undo moves. Pick the right verb.

Cancel stops an action before it completes. It leaves no trace downstream. It is the cheapest undo and it is time-boxed.

Reverse adds an opposite entry after completion. The original stays on the books. A refund is the standard case.

Compensate makes the customer whole when you cannot reverse. You rebook the lost slot, credit the fee or call the person back.

Microsoft's saga pattern adds a useful term: the pivot transaction, the "point of no return." After it succeeds, you finish forward instead of unwinding. Mark the pivot in every multi-step flow. For a pizza order, the pivot is the ticket printing in the kitchen. For a lending flow, it is the disclosure going out. Our workflow testing guide takes the state-machine view of this.

Example: card payments, cancel versus refund

Payment processors show the three verbs clearly. In card terms, a void is a cancel before capture. A voice agent refund workflow starts after capture. We use Stripe's public documentation as one example. Check your own processor, because semantics differ.

Per Stripe's refund and cancel docs, you can cancel a payment before it completes at no cost. You can refund after it succeeds, which "might incur a fee." Stripe's processing fees from the original transaction are not returned. A PaymentIntent in `requires_capture` cannot be refunded directly. You cancel it. A succeeded PaymentIntent cannot be canceled at all.

Refunds have their own failure modes. Stripe says refunds go only to the original payment method. Customers see the credit "approximately 5-10 business days later." Refunds issued shortly after the charge may appear as a reversal, so the original charge drops off the statement. A refund can fail, and the money can take up to 30 days to return to your balance. Only some card refunds can be canceled, and only through the Dashboard.

Here is a worked example. The numbers are illustrative. The caller says "eighty-four dollars." The agent charges $840.00.

1. If you authorize first and capture later, cancel the hold. No money moved. The customer may still see a pending line for a short time.

2. If the charge captured, issue a refund of $840.00 and a new charge of $84.00. The customer waits days for the credit.

3. Tell the customer on the next contact what happened. They will notice a large pending charge before any refund lands.

The lesson for design: where the business allows it, authorize, read back the amount, then capture. That turns a class 3 mistake into a cheap cancel. We cover the capture design in taking payments by phone. The failed-payment call flow in gym failed-payment calls shows how a wrong amount or card cascades into billing records.

Example: bookings and holds

A booking is class 2. To reverse a voice agent booking, release the slot. That is easy if nothing consumed it. It is hard once a downstream system acted. A service lane may have ordered parts. A crew may have been routed. See dealership service scheduling for a flow where a wrong vehicle ID reaches the parts desk.

Use a two-state booking. The agent creates a `tentative` booking. A confirmation step, after read-back, moves it to `confirmed`. Downstream systems act only on `confirmed`. That is a semantic lock in the saga sense. It shrinks the set of bookings that need compensation when the agent is wrong.

Messages cannot be recalled

Class 4 is where teams get surprised. A sent text is gone. For notices, the voice agent rollback actions are a delayed send and a correction message.

Twilio's docs show the boundary. Its error 30409 page says only scheduled messages can be canceled. Once a message is queued, sent or delivered, it can no longer be canceled through the Message resource. Cancellation needs a Messaging Service. So there is exactly one window to stop a text: before it leaves.

Two design moves follow.

• Delay the send. Put confirmations in a short scheduled queue. A caller who says "wait, that's wrong" before hanging up can still cancel the text. Choose the delay by flow and test it. If you use Twilio's own scheduling, note that it requires a Messaging Service and a send time at least 15 minutes ahead, so a shorter hold needs your own queue in front of Twilio.
• Write correction templates ahead of time. A wrong text needs a clear second text. Draft it now: what was wrong, what is right, what to do. Do not improvise during an incident.

Consent adds a clock. The FTC's CAN-SPAM guide says you must honor an email opt-out request within 10 business days (as of November 2026). If a bad deploy sent messages to people who opted out, you owe a fix on that clock. Texts fall under separate consent rules that we did not review here. Have counsel confirm your obligations. This is not legal advice.

Clocks that start when the error happens

Some undo work has a deadline you do not control. Money is the main case.

If your flow moves funds electronically from a consumer's account, Regulation E may apply. Under 12 CFR 1005.11, an institution must determine whether an error occurred within 10 business days of a notice. If it needs longer, it generally must provisionally credit the account within that window, subject to limited exceptions. It may then take up to 45 days to finish, and 90 days in some cases, such as point-of-sale debit transactions. Notice can arrive up to 60 days after the periodic statement.

Whether a given payment is covered depends on the payment method and who holds the account. Credit card disputes follow other rules that we did not review here. The practical point is the same for any regime. Your detection and undo speed becomes part of someone else's compliance clock. Put that in the runbook. Our financial services testing guide goes deeper on regulated flows.

The action ledger: who did what, when

You cannot undo what you cannot find. A voice agent audit trail makes every one of your voice agent rollback actions possible. Most call logs hold audio and a transcript. That is not enough. You need a row per action, written at the moment the tool runs.

The ledger answers four questions. Which call did this? Which prompt, model and tool version? What exactly changed? Has it been undone? Microsoft's compensating transaction guidance says you should be able to "correlate and audit both the original operation and its compensation end-to-end." That is this table.

{
  "action_id": "act_01HZX...",
  "call_id": "call_8f21",
  "ts": "2026-11-05T14:07:31Z",
  "tenant_id": "store_117",
  "tool": "create_booking",
  "tool_version": "2026-10-28",
  "prompt_version": "p-412",
  "model": "model-id-here",
  "class": 2,
  "idempotency_key": "call_8f21:create_booking:1",
  "args": {"slot": "2026-11-07T15:00", "service": "tune-up"},
  "result": {"status": "ok", "record_id": "bk_5531"},
  "caller_confirmed": true,
  "undo": {"state": "none", "by": null, "ref": null}
}

Four fields earn their place. `class` lets you triage. `prompt_version` and `tool_version` give you the blast-radius query. `idempotency_key` makes the undo safe to retry. Stripe's idempotent request docs note that for API v1 a key can be pruned after at least 24 hours, so your own ledger must outlive the processor's window. `undo` turns the ledger into a work queue. See what to log on voice agent calls for the call-level fields around this.

Keep the ledger append-only. An undo is a new row that points at the old one. Never edit history. A reviewer must see both the mistake and the fix.

Finding every affected record after a bad deploy

A bad prompt change ships at 14:00. Someone notices at 17:30. How many records are wrong?

If your ledger has versions, the query is short.

SELECT class, tool, count(*) AS actions, count(DISTINCT call_id) AS calls
FROM agent_actions
WHERE prompt_version = 'p-412'
  AND ts >= '2026-11-05T14:00:00Z'
  AND undo_state = 'none'
GROUP BY class, tool
ORDER BY class DESC, actions DESC;

This is the blast-radius query. It sizes the undo work you owe. Our blast radius guide explains why one change reaches many tenants. Here is a worked example with illustrative numbers.

• Window: 14:00 to 17:30, 3.5 hours.
• Volume: 60 calls per hour, so 210 calls.
• Assume 70% of calls hit a write tool. That is 147 calls.
• Class mix: 90 soft or hard writes, 30 notifications, 20 payments, 7 class 5 attempts.

Now the work is clear. Fix 90 records by script. Send corrections to 30 people. Refund or cancel 20 payments, starting with the oldest. Send the 7 class 5 cases to a human today.

The count of 147 is only the cases the ledger shows. Some wrong outcomes never touch a tool. A caller may have hung up believing a wrong answer. For those, you need call-level review, which production monitoring can support.

Pick the undo path

Not every error needs the same response. Choose with a short decision path.

Three rules sit under the tree.

1. Try cancel first. It is cheap and leaves the cleanest record.

2. Reverse or compensate by script only for class 1 to 3. Scripts need a dry run and a count check first.

3. Humans own class 4 and 5, and any customer-facing choice. Microsoft's guidance on travel bookings says the customer, not the system, should decide between a substitute and a cancellation. High-impact or hard-to-automate decisions need a person.

A human review queue needs structure. Each item should show the call audio, the ledger row, the proposed fix and the deadline. Reviewers should approve, edit or reject. Log their choice in the ledger too.

Testing undo paths before you need them

Most teams test the forward path and never run the undo. Then the first real undo happens during an incident. Test undo like any other feature.

• Caller-driven undo. A caller changes their mind mid-call: "cancel that," "actually Friday." Check that the agent calls cancel, not a second create. Our tool-call test cases cover the pattern for correct tool choice.
• Compensation scripts. Run them against staging data. Check the dry-run count equals the ledger count. See staging for voice agents.
• Idempotent undo. Run the refund script twice. The second run must do nothing.
• Silent failures. An undo that returns 200 but changes nothing is the worst case. Our silent tool failure guide shows how to catch it.

Evalgent can generate test scenarios from the agent's prompt and flows, including branches where callers reverse a choice. Its simulator calls the agent over phone, SIP or WebRTC with caller profiles for accent, pace, interruptions and background noise. It judges from the audio, not only the transcript, which matters when the failure is a misheard amount. That gives you a regression suite for the cancel and change paths before each prompt change ships. See also shipping prompt changes safely.

In production, Evalgent's call monitoring takes your call recordings, maps them to scenarios and flags tool-call failures, policy failures and PII leakage. After an incident, that helps you find calls beyond the ledger's rows. Our production monitoring guide shows the wider setup.

How to build a runbook for voice agent rollback actions

Write this before the first incident. Keep it to one page. It lists the steps in order.

1. Inventory your tools. List every action the agent can take. Assign each a class from 0 to 5.

2. Mark pivots and holds. For each multi-step flow, name the pivot. Add tentative states where you can.

3. Add the ledger. Write one append-only row per action. Include class, versions, key and undo state.

4. Define the freeze. Decide who may pause a tool or revert a prompt, and how fast. Write the exact switch.

5. Write the blast-radius query. Save it with parameters for version and time window. Test it on staging.

6. Write undo scripts per class. Include a dry run, a count check and a stop on error. Make each idempotent.

7. Prepare correction messages. Draft templates for each notification type, with approval from whoever owns the brand and the legal risk.

8. Set the review queue. Assign owners for class 4 and 5 items. Set deadlines tied to any regulatory clock.

9. Drill it. Replay a seeded bad deploy in staging once a quarter. Time how long each step takes.

A template you can copy:

INCIDENT: <prompt/tool version> bad from <start> to <end>
1. Freeze: disable <tool> or revert to <last good version>. Owner: ___
2. Count: run blast-radius query. Record counts by class.
3. Stop the bleeding: cancel pending class 3-4 actions in queue.
4. Fix: run undo scripts for class 1-3 (dry run, then live).
5. Notify: send correction messages after approval. Owner: ___
6. Review: humans clear class 4-5 items. Deadline: ___
7. Verify: re-run query. Expect zero rows with undo_state = none.
8. Record: write the cause, the counts and the new test.

Step 8 matters most. Every incident should end with a new test. Otherwise it will come back. Our production feedback loop post shows how to turn incidents into regression cases.

Frequently asked questions

Can you undo what an AI voice agent did?

Sometimes. Soft writes and bookings can usually be canceled. Payments can be canceled before capture or refunded after. Sent texts and emails cannot be recalled, only corrected. Legal actions need a human before they happen. Sort each tool by class first, so you know the answer before an incident.

How to roll back a voice agent change?

Voice agent rollback actions start with a revert. Revert the prompt or tool to the last good version, then freeze affected tools. That stops new damage. Rolling back the code does not fix records already written. Run the blast-radius query for the bad version and window, then undo each action by class.

How do you refund a payment taken by a voice agent?

If the charge is only authorized, cancel it. If it is captured, issue a refund through your processor. Stripe says refunds go to the original payment method and appear in approximately 5-10 business days, depending on the bank. Confirm your own processor's rules. Tell the caller what to expect.

Can a voice agent text message be recalled?

No. Twilio's docs say only scheduled messages can be canceled. After a message is queued, sent or delivered, you send a correction. Hold confirmations in a short queue (Twilio's own scheduling needs at least 15 minutes) so a caller's "wait, that's wrong" can still stop the text.

What is a compensating action in a voice agent?

It is a new action that offsets an earlier one you cannot reverse. Examples are rebooking a lost slot, crediting a fee or calling the customer back. Microsoft notes compensation may not restore the original state. It makes the outcome acceptable instead.

How do you find every record a voice agent changed?

Build a voice agent audit trail: one row per action with call ID, prompt version, tool version and result. After a bad deploy, filter by version and time window. Group by tool and class. Without version fields, you are reading transcripts one by one.

What should a voice agent audit log contain?

Record who acted, what changed, when, which call, and the result. For agents, add prompt version, tool version, action class, idempotency key and caller confirmation. Add an undo state. Keep it append-only so reviewers see both the error and the fix.

When should a voice agent hand an undo to a human?

Use a human for sent notifications, legal or regulated actions, and any choice the customer should make. Also escalate when a script fails twice or the count does not match. High-impact decisions need a person. Give the reviewer the audio and the ledger row.

The bottom line

Voice agent rollback actions are a feature you design before launch, not a scramble after an incident. Classify every action, log it with versions, and rehearse the undo.