When an Automation Goes Down, How Does the Work Keep Moving?

Start with the work that must continue

Choose one important business job, such as accepting service requests and creating draft work items. Name the point at which delay becomes costly, which cases deserve priority, and who can choose the fallback. An outage plan needs to describe what staff should do while the builder diagnoses the fault.

Separate steps that remain useful from steps that depend on missing information. Intake might continue while scheduling pauses. Drafting might continue while sending stays blocked. If the destination itself is unavailable, recording a request in an approved holding place may be the only permitted action. Do not describe all manual work as a safe substitute.

In The Automation Advantage, Bhaskar Ghosh, Rajendra Prasad, and Gayathri Pallail discuss resilience in Chapter 9. Stafford Beer’s Brain of the Firm, Chapter 10, asks how an organization changes its operating mode during disruption. The operating states and reconciliation exercise below are our practical adaptation, not a recovery method demonstrated by either book.

Make the permitted actions clear in each state

Write down how the workflow enters and leaves each operating state. Give staff an accessible way to see the current state, its owner, and when it was last checked. The labels can match existing tools; the important part is that everyone understands what they permit.

• Normal: the agreed source, destination, and approval checks are available, and ordinary processing is permitted.
• Degraded: named steps can continue under a documented fallback. Define the conditions, access, and person responsible for each manual action.
• Paused: affected actions are blocked. Accepted requests remain visible with their priority, owner, and reason for waiting.
• Recovery: the connection is available, but pending work stays controlled while the team compares automated, manual, and destination records. The authorized owner decides when ordinary processing resumes.

Give fallback work the same identity as queued work

Keep one controlled record of what happened to each business item. Record its source reference, intended action, current state, person handling it, completion evidence, and any uncertainty. A chat message saying “handled” is difficult to reconcile if it does not identify the work or its resulting record.

Before someone acts manually, check whether an automated attempt might already have succeeded. Assign the item so another person does not handle it simultaneously, using the system’s supported controls. If reliable checking or coordination is unavailable, hold the consequential action for investigation. Urgency does not turn uncertainty into permission.

Keep fallback access and approval boundaries intact. Moving data to an unapproved spreadsheet or sending through a personal account creates a different problem. Prepare the permitted holding place and instructions before the outage.

Worked example: an interrupted batch and a manual completion

This synthetic example uses four draft work items, labeled A through D. The automated connection fails while authorized staff can still use the destination application. The labels and event order are invented; no customer records or live service were involved.

• Before interruption: A is created and its success is recorded. B is also created, but its acknowledgment never reaches the automation.
• During the outage: B remains uncertain. An authorized employee creates C manually and records its destination reference. D has not started. B, C, and D still appear in the automation’s waiting queue.
• At reconnection: a restart based only on the automation’s success log would attempt B, C, and D. The team first compares the queue with current destination evidence and the manual record.
• After reconciliation: A needs no further action. B and C have verified existing results. Only D is eligible for a new creation, subject to its current instructions and approval.

What a small restart model establishes

We ran a bounded local model of that example. Replaying every queued item absent from the success log produced two copies each of B and C. Reconciling against the model’s destination list left one copy of each item and created only D. These are simulated record counts, not an AIify implementation result.

The model assumes perfect reads of a complete destination list, unique item references, and no concurrent writers. It has no network delay, crash recovery, permissions, or approval engine. It illustrates why a local success log can be insufficient; it does not prove a live integration can prevent duplicates. Test the real destination’s lookup, update, and retry behavior separately.

Use the same reconciliation discipline during parallel running

A migration can create a quieter version of the restart problem. The old workflow remains responsible for live work while its replacement runs without action permissions. If their source changes and completion histories diverge, comparing their latest outputs mixes two questions: does the new logic behave differently, and did it receive the same facts?

We ran this synthetic timeline with the same deterministic eligibility rule on both sides: propose creation only for a ready request with no existing destination result. The clock labels are invented ordering markers. No live application or AI model was involved.

• 09:00: both paths see source version one, with A and B ready and no destination records. Both propose A and B. Only the old path would be authorized to act.
• 09:10: in the scenario, the old path has completed A and the source owner has canceled B. The shadow copy has received neither update. The old path proposes nothing; the shadow still proposes A and B. Those two disagreements reflect different histories, despite identical logic.
• 09:20: rebase the shadow against source version two and the verified destination result for A. Both now propose nothing. B remains canceled, and A does not need another creation.

Make cutover depend on reconciled evidence

The calculation assumes complete, instantaneous snapshots and unique references, with no concurrent changes. It illustrates state drift; it does not establish that a real platform can snapshot, export, replay or recover reliably. Verify those capabilities before relying on them, and keep uncertain items held if the necessary evidence is unavailable.

Define why the parallel period exists, who owns it and what evidence permits ending it. Compare identified cases against known source and rule versions. Before an approved cutover, account for completed actions, pending approvals, cancellations, unresolved items and arrivals around the boundary. Establish which path owns the next permitted action, so enabling the replacement cannot leave both paths active.

Agree a bounded recovery plan too: what would trigger a return, who may decide it and how work performed after cutover would be reconciled. A rollback that restores old configuration without its missing action history can recreate the very drift it is meant to resolve.

In chapter 14 of Planning for Human Systems, page 197, Stafford Beer describes parallel systems whose accounts of reality increasingly diverged. Taylor distinguishes experience of operating a system from experience of introducing it in The Principles of Scientific Management, pages 132–134. Ask a provider to show transition evidence and an authorized recovery procedure, as well as the finished-system demo. The historical accounts do not justify an irreversible rollout.

Classify the queue before releasing it

For each queued action, choose a disposition supported by evidence: completed and verified; still needed and eligible; changed and needing a new decision; or uncertain and held. Keep a reason and owner for every held item. An uncertain outcome deserves its own category because treating it as failure can repeat work, while treating it as success can lose work.

Recheck instructions and approvals that aged during the outage. A canceled request should not reappear merely because its old event remains queued. Record a clear recovery boundary so new arrivals and older waiting work are both accounted for. Where supported, use stable action identifiers and destination-side duplicate protection; ask exactly what they cover and how long their protection lasts.

Resume at a pace the receiving team can handle

An available connection does not establish that the receiving system or its human reviewers can absorb the backlog. Release a bounded set of eligible items, inspect their resulting records, and check whether waiting work is growing elsewhere. Agree how urgent cases and ordinary arrivals share the available capacity.

Keep repeat attempts limited and give persistent failures a visible destination. A delay between attempts can reduce pressure, but it cannot resolve a contradictory business rule or an unknown earlier outcome. If evidence becomes unreliable again, return affected actions to the agreed paused state.

Finish the rehearsal with evidence

Use synthetic items to rehearse interruption after a write, manual completion, changed instructions, an unavailable owner, and reconnection with an existing backlog. Check the final destination, the waiting queue, and any customer-facing side effects. Every accepted item should have a verified result or an explicitly owned reason for remaining open.

Keep the exercise’s assumptions and gaps with the plan. The useful deliverable is a procedure another authorized person can follow: what continues, what waits, what evidence permits recovery, and who decides. Review it after material changes to the workflow or the people responsible for it.