# Rollback plan for an AI workflow: what can still be put back after it acts

A rollback plan for an AI workflow has to say what can be put back after the system acts. Restoring the last working version covers the code. Actions waiting to happen should stay editable until they run, and data already written needs its own answer, because reverting the code does not unwrite anything.

Date: 2026-11-02
Reading time: 3 min
Author: OCTYN
No. 20

Somewhere in the paperwork for a new system there is a line about rollback, and the head of operations reads it as a promise that any mistake can be undone. Say the system places replenishment orders for a grocery chain overnight, and one night it misreads a supplier's pack size and orders cases where the stores wanted single units. Somebody puts the previous version back before breakfast. The orders are still with the supplier.

So **a rollback question gets asked twice, once about the code and once about what the system has already done**, and a plan that answers only the first leaves the grocery chain on the phone to its supplier.

## Putting the code back

For code, the rollback worth having is the boring one. On octyn.co it is **a revert and a push, the same path as any deploy**, so there is no separate emergency procedure for somebody to get wrong at two in the morning, and a build that does not compile never replaces the one running. [Mooney](/casestudies/mooney), the expense app OCTYN runs, ships through an app store, so a bad build halts partway through a staged rollout instead of being recalled from every phone.

Then ask whether anyone has done it. The first attempt always uncovers something dull, like a migration that does not reverse or credentials nobody has, so it is worth asking who last ran the [rollback](/glossary/rollback), and when.

## Actions still waiting to happen

Most of what an operations system does sits in a queue for a while before it acts, and **that wait is the easiest place to undo anything**. In the outreach system OCTYN runs for [an independent craft retailer](/casestudies/craft-retail-brand-sales), rollback is per action: a queued message can be changed or cancelled up to its send time, and the changed version is the one that goes. That mattered on 12 August. A rerouting step had queued a cold first message to a third person at a company already talking to the retailer, and it was cancelled sixteen minutes before it would have gone out.

For the grocery chain, the same idea is an order that waits with a time on it, where a buyer can change the quantity or pull it before the supplier sees anything. A [dry run](/glossary/dry-run) on the first night would have caught the pack size on paper.

## Data the old version cannot unwrite

If the system wrote something wrong to the database, going back to the old code leaves the wrong rows where they were. Deletes are worse. One of OCTYN's own databases had two links set to cascade, so removing one record quietly removed linked records that had taken days to collect. Both links now refuse. **A delete that would take other data with it is blocked, and it says what it is blocking**.



Before the system goes live, hand this to whoever will run it and ask for an answer in every row.

| What went wrong | What puts it back |
|---|---|
| a bad version of the code | the last working version, on the normal deploy path |
| an action still in the queue | a change or a cancel before its time comes |
| an order already with the supplier | a person, on the phone |
| rows written or deleted | only what the database refused to do in the first place |

If the answer in the bottom row is the backups, ask when somebody last restored one.

## Related

**Case studies cited**

- [Brand sales for an independent craft retailer](https://octyn.co/casestudies/craft-retail-brand-sales)
- [Mooney](https://octyn.co/casestudies/mooney)

**Terms used here**

- [Rollback](https://octyn.co/glossary/rollback)
- [Dry run](https://octyn.co/glossary/dry-run)
- [Operating partner](https://octyn.co/glossary/operating-partner)

**The longer argument**

- [What production ready means for an AI system](https://octyn.co/compare/production-ready-ai-system)

**Read next**

- [Monitoring an AI workflow without an engineering team starts with a morning read](https://octyn.co/blog/monitoring-an-ai-workflow-without-an-engineering-team-starts-with-a-morning-read)
- [Should an AI agent send your emails? Ours did, once](https://octyn.co/blog/should-an-ai-agent-send-your-emails)
- [Tracking a trade order from quote to delivery without losing status midway](https://octyn.co/blog/tracking-a-trade-order-from-quote-to-delivery-without-losing-status-midway)
- [How much does an AI system of your own cost, and what it costs to change later](https://octyn.co/blog/how-much-does-an-ai-system-of-your-own-cost-and-what-it-costs-to-change-later)

More on automation that holds up: [Automation that holds up](https://octyn.co/blog/topic/reliable-automation)

Canonical: https://octyn.co/blog/rollback-plan-for-an-ai-workflow-what-can-still-be-put-back-after-it-acts