AI Agent Business Continuity Plan: Keep the Manual Skill Alive

An AI agent business continuity plan must cover three failures: the provider goes down, the model quietly gets worse, or the agent does wrong things on live systems. A tested second model helps with the first. What covers all three is a manual path that people can still run, and most plans assume that path exists without checking. This piece is for the owner or operations lead of a business that runs invoicing, support or scheduling through an agent. You get a dependency map, a runbook outline, a capacity rule and a drill routine you can set up this month.

Two dated facts frame it. In May 2026, Singapore's IMDA added detail to its agentic AI framework on how staff lose the skill to do agent-run work by hand. And in August 2026, Claude's official status page listed 25 incidents across claude.ai, the Claude API, Claude Code and related services, eight of them rated major or critical by Anthropic. Those are the vendor's own labels, not an uptime figure. The regulatory references here are Singaporean; the operating advice applies anywhere.

What can actually go wrong when an AI agent fails?

An AI agent fails in three distinct ways, and each needs a different response. A provider outage is loud: errors, timeouts, an incident on a status page. A bad model update is silent: the agent still answers, but worse. A runaway agent is active: it does the wrong thing, fast, on real systems. Most continuity plans are written only for the first.

Provider outage. The model behind your agent is someone else's service. On 29 July 2026, Anthropic's status page recorded elevated errors across Claude models from 19:45 to 21:26 UTC, about an hour and 40 minutes. On 16 August a disruption hit claude.ai, the console, the API, Claude Code and Claude Cowork for about 36 minutes. A month-end payment run does not care which kind it gets. It cares whether anyone knows what to do in the meantime.

Silent degradation. This one slips past monitoring. In its postmortem of 17 September 2025, Anthropic wrote that "three infrastructure bugs intermittently degraded Claude's response quality" between August and early September, and that "the evaluations we ran simply didn't capture the degradation users were reporting." OpenAI's case was different in cause and similar in effect: on 29 April 2025 it rolled back a GPT-4o update in ChatGPT because the new version was "overly flattering or agreeable". Both services stayed up. The output had changed.

Runaway agent. In July 2025 a SaaStr founder reported that Replit's coding agent, used in his public experiment, deleted his production database during a code freeze he had declared and invented data. Those details are his account. Replit's chief executive, Amjad Masad, replied in a post on X that it was "Unacceptable and should never be possible" (reported by The Register, 22 July 2025). That was a coding agent with wide access, not an invoicing tool. The lesson that transfers is narrower: stop the agent, restore from your own records, and do not trust the agent's story of what it did.

The table below shows why one fallback cannot cover all three, plus a fourth failure that builds up underneath them.

Why is losing the manual skill the bigger risk?

Losing the manual skill is the bigger risk because outages end on their own and skills do not return on their own. IMDA's Model AI Governance Framework for Agentic AI, version 1.5 (published 20 May 2026, updated 5 June 2026), says skill degradation "can create business continuity risks in which users may no longer know how to perform critical processes manually when agents malfunction or become unavailable."

The mechanism IMDA gives is more specific than "people get rusty". Section 2.4.3 says that as agents "take over entry-level tasks, which typically serve as training for new staff", users can lose basic operational knowledge. So the damage lands on the people you hire after the agent goes live. Your senior clerk still knows how to match an invoice by hand. Her replacement, hired a year later, has only ever clicked approve on the agent's match. Turnover quietly converts a skills risk into a continuity risk.

How fast does it happen? Nobody has published a measurement for invoice or scheduling clerks. The nearest careful result is narrower: in an observational study at four Polish endoscopy centres, Budzyń and colleagues (Lancet Gastroenterology and Hepatology, 2025) found adenoma detection on colonoscopies done without AI fell from 28.4% (226 of 795) to 22.4% (145 of 648) in the three months after AI assistance was introduced. One procedure, one specialty, and not the new-hire mechanism IMDA describes. Treat it as a reason to time your manual path this quarter, not as a forecast for your team.

The framework is voluntary guidance, not law, and its ask is modest: "identify core capabilities of each job and provide sufficient training and work exposure so that users retain foundational skills." The hard part is motivation. When an agent works well, practising the old way feels like waste.

For the managing director, the plain question is: if the agent disappeared for a week, who would do the work, and how slowly? For operators, it is personal. The skill you stop practising is the skill you are expected to have on the worst day of the quarter.

How do you map what your agent depends on?

List everything that must work for one agent-run process to finish: provider, model version, tools and credentials, task records, and the people who can do it without the agent. MAS's Guidelines on Business Continuity Management (June 2022) call this mapping "end-to-end dependencies covering people, processes, technology and other resources (including those involving third parties)."

This is general information, not legal advice. The MAS guidelines apply to financial institutions, which MAS says are "encouraged to adopt" them and whose continuity management it reviews against them. For other businesses they are a well-tested template, not an obligation. They predate the agent boom and still fit it.

Two details on the map get less attention than they deserve.

First, the vendor status page is itself a dependency. On 14 August 2026, Anthropic logged an incident titled "Issues reaching status.claude.com" that lasted almost three hours. It did not coincide with a model outage, but it shows the page can be unreachable too. Watch your own error rate and queue age instead.

Second, task state is where recovery goes wrong. When an agent stops mid-run, some invoices are matched, some are paid, and some are half-written to your accounting system. Give every task an ID that the agent writes into the record it changes, so a person can search for it and avoid doing it twice. Record each action in the system it touches, so you can rebuild the picture without asking the agent. Our post on what an agent audit trail must answer sets out the fields.

For the CTO, one test covers it. Pick one process. Can you name its model version, every credential it holds, and the record that shows which of yesterday's tasks finished? If any answer is "I would have to check with the vendor", that is a gap.

What goes into a manual fallback runbook?

A manual fallback runbook is a two-page procedure telling a named person when to stop the agent, what to do by hand, what can wait, and how to hand back. MAS lists "manual workarounds" among its examples of recovery strategies, and expects activation criteria for "partial disruption (including intermittent or reduced performance that is not tantamount to a complete unavailability of service)."

That partial-disruption clause, written in 2022, is the sentence in the MAS guidelines that fits agents best. Take the August 2026 incidents on Claude's status page that listed the Claude API as affected: there were 16, and Anthropic rated 11 of them minor and five major or critical. Most were titled elevated errors or degraded performance, and from open to resolved they ran from 15 minutes to just over seven hours. Those are the vendor's labels, but they point one way. Partial failure is the normal shape. A runbook that triggers only on a full outage will sit unused while the agent misfiles work for an afternoon.

A workable runbook covers:

• Triggers. Our suggested starting points, not a standard: error rate above 5% of calls for 15 minutes, queue age past your target, a failed test-set rerun after a model change, or any action outside the agent's allowed list. Tune them after the first drill.
• Stop. Who pauses the agent and who revokes its credentials, without waiting for the vendor.
• Minimum service. Which work must continue by hand, and which can wait for the agent to return.
• Reconcile. How to find half-finished tasks by their IDs in system records.
• Hand back. The test set passes, then a supervised batch of about 20 tasks is checked before full volume resumes.

The minimum-service line needs a number behind it. Our capacity rule: the must-do work in the window, divided by the hourly pace of the slowest person likely to be on shift, must fit in the hours before the deadline with a quarter to spare. If it does not, cut the must-do list now or train a second person.

Illustrative example: a 40-person distributor runs supplier invoice matching through an agent, about 320 invoices a day. Before the agent, two clerks handled 160 each. One has since left, and the new hire has only reviewed the agent's matches. On the last day of the month the provider has a four-hour problem, so about 160 invoices back up. At a trained clerk's pace of 20 an hour, one person clears that in eight hours. At an untrained pace of 8 an hour, it takes 20 hours, past the payment run. The runbook's answer is the minimum service rule: pay only the 40 invoices due within 48 hours by hand, about five hours even at the newer clerk's pace, and leave the rest for the agent. The decision was written down in advance, so nobody has to invent it at 5pm.

The calculator below applies the capacity rule to your own numbers.

How often should you drill, and what should you measure?

Drill the manual path often enough that a real person, working without the agent, can still meet your recovery target. For most SME processes that means one timed manual session per quarter for each agent-run process, with the backup person rotating, plus a walk-through of the stop and reconcile steps twice a year.

Testing serves the same purpose in the MAS guidelines, which say tests should "familiarise personnel" with their roles and verify that recovery targets "can be met". Separately, MAS lists cross-training as a way to manage concentration of critical skills. IMDA's v1.5 framework names a similar fix for agents: "sufficient training and work exposure."

Measure three things in each drill. Time per task against your target. Errors in the manual work, checked by a second person against source documents, not against the agent's output, because the agent may be the thing that has drifted. And the runbook steps that turned out to be wrong. If the manual pace drops between drills, drill more often or rotate more people through the work.

The cost is small. Ten tasks by hand plus a second person's check is about an hour or two a quarter for each process at the paces in the example above. Compare that with the 20-hour backlog.

Drills also catch silent degradation. When a person does 30 tasks by hand and the agent's results on the same items differ, check both against the source. Differences that favour the person are a quality drop no dashboard flagged. Compliance teams can use the drill records too: they are dated evidence that the fallback works, which is what an auditor or a customer's vendor review will ask for.

Use the check below to see where your continuity plan stands today.

Where Origin Pi stands

Our view is that an agent without a working manual path is a single point of failure dressed up as efficiency. The outage is rarely what hurts. What hurts is the day the agent stops, or starts doing the wrong thing, and the team has lost the habit of doing the job itself.

So we design agent-run processes with the exit built in. Each agent gets bounded permissions, so a runaway has a ceiling. Each action is written to an audit trail in the system it touches, so recovery starts from facts, not from the agent's own story. Each consequential step has a confirm step that a person owns. Those same records make the manual drill and the hand-back measurable. They are the readiness controls we cover in why agent projects get cancelled, and they sit at the centre of our business automation work.

Your next step: pick the agent-run process that would hurt most on a month-end. This week, ask the newest person on that team to do ten of its tasks by hand while someone times it. That number is your real recovery capacity. Write the runbook around it.