Business Continuity Plan for AI Agents: Prepare for Outages

A business continuity plan for AI agents names the work the agent does, what happens to that work when a model, tool or channel stops responding, and who takes over by hand. It defines fallback modes in advance, keeps short manual procedures current, and ends with recovery checks that confirm nothing was lost, duplicated or sent twice. Write it before the first outage, because the decisions are easier to make calmly.

Key takeaways

• Plan around the work, not the technology. For each task, decide how long it can wait and who does it by hand.
• Define a small set of fallback modes, from normal operation down to a full pause, and say who may switch between them.
• Keep each manual procedure to one page: trigger, owner, steps, where to record what happened, and what to tell the people affected.
• Recovery is its own phase. Reconcile what the agent did against the system of record before returning to normal.
• Drill the plan on a quiet day. An untested fallback is a guess.

What should a continuity plan for an AI agent cover?

The plan covers the role the agent plays, not the model behind it. A model is one dependency among several. The agent also relies on tools it calls, channels where people reach it, a memory or knowledge store, and credentials that let it act. Any of these can fail while the others work.

Start with the tasks. For each one, write down three things: what the business loses if it waits, how long it can wait before that loss matters, and which person or team can do the task without the agent. A task such as drafting a weekly summary can wait a day. A task such as confirming an urgent service visit may need a human within the hour. The answers decide how much fallback each task deserves.

Put the result in the same place as the rest of your operating notes. If you already keep a runbook, the continuity plan is a section of it. AI Agent Runbook: The Operating Notes Worth Keeping describes what such notes should hold so that someone other than the original builder can use them under pressure.

Which failures should you plan for?

Plan for categories, not for every possible incident. Most outages fall into a handful of shapes, and each shape has a different safe response.

• Model unavailable or very slow: the agent cannot reason or answer within the time the task allows.
• Model behavior changed: the service is up, but outputs differ from what your tests expect.
• Tool or integration down: the agent can think but cannot read from or write to a calendar, CRM, spreadsheet or ticket system.
• Channel down: people cannot reach the agent, or the agent cannot reach them, in chat, email or messaging.
• Memory or context unavailable or stale: the agent runs without the notes it depends on, or with notes that are out of date.
• Credential expired or permission revoked: a token lapsed, an account was changed, or access was cut on purpose.
• The agent itself is acting wrongly: it is available, but you need it to stop.

The last item matters most and is often missing. A continuity plan is not only about things going quiet. It must also say who can stop the agent, how, and what happens to work in progress when they do.

How do you design fallback modes?

A fallback mode is a pre-agreed level of operation with a clear description of what the agent may and may not do. Give modes plain names so anyone on the team can say which one is active. Use this list as a decision guide, and pick the lowest mode that still protects the outcome.

• Normal: the agent works with its usual model, tools and approvals.
• Degraded: a backup model or a reduced set of tools is in use. The agent handles only the tasks you have tested in that configuration and hands the rest to people.
• Draft only: the agent prepares work but a human sends, books or submits it. Use this when a write tool is unreliable or when output quality is in doubt.
• Queue only: the agent captures incoming requests, confirms receipt where that is safe, and takes no action. A human works the queue.
• Paused: the agent does nothing. Staff follow the manual procedures, and a short notice tells affected people where to go.

Two cautions apply. First, a backup model is not a copy of the primary one. It may follow instructions differently, so run it against your golden test set before you rely on it, and limit its scope to tasks that passed. Second, do not let the agent decide on its own to move to a higher-authority mode. Moving down in capability can be automatic. Moving back up should require a person to confirm.

What manual procedures should exist before an outage?

A manual procedure is what a person does when the agent cannot. It should be short enough to follow while interrupted. One page per critical task is a reasonable limit, and it should contain the following.

• Trigger: how someone knows the procedure applies, such as a status message, a missed heartbeat or a report from a colleague.
• Owner and backup owner: named roles, not a team alias nobody watches.
• Steps: the actual actions, using the same systems of record the agent uses, with the same rules it follows.
• Record: where to note what was done by hand, so the agent or a reviewer can reconcile later.
• Message: the sentence to send to customers, partners or colleagues who are waiting, written in advance and approved.
• Exit: what must be true before the agent takes the work back.

The record step is the one teams skip. When a person books an appointment manually during an outage and the agent later replays its queue, you get a double booking. A single shared log, even a plain document, prevents most of that.

Handoffs should carry the decision, not a pile of raw context. Human escalation for AI agents: send the decision, not the mess covers how to package a case so the person taking over can act at once.

What does an outage look like in practice? An illustrative scenario

This scenario is illustrative, not a report of a real case. A small services firm uses an agent that reads inbound requests in a team chat channel, proposes time slots, and writes confirmed visits into a scheduling tool.

One morning the scheduling tool starts timing out. The agent can still read requests and reason about them, but its write calls fail. A well-built agent does not keep trying. It follows its retry rules, stops after the allowed attempts, and switches to queue only for anything that needs a booking. It posts one message to the coordinator listing each pending request with the slot it would have proposed. Guidance on bounding attempts is in An AI agent retry policy that avoids repeated mistakes.

The coordinator uses the one-page procedure: confirm the visits by phone, write each one into the shared log, and send the pre-approved message to anyone who has to wait. When the tool recovers, the agent does not replay its queue blindly. It first compares its pending list with the shared log, drops what was already handled, and asks the coordinator to confirm the rest.

Nothing in this flow is clever. It works because the mode, the owner, the log and the exit condition were decided earlier.

How do you recover safely after the outage?

Recovery is where quiet damage happens. Services return, queues drain, and duplicated or stale actions go out. Treat the return to normal as a sequence with checks, not a switch.

• Confirm the cause is resolved by running a small, harmless action against the recovered model, tool or channel.
• Freeze new automated writes until the next steps are done.
• Reconcile: compare the agent's action log with each system of record for the outage window, and list actions that were started but not finished.
• Look for duplicates and partial actions, such as a message sent without the matching record update.
• Review queued items for age. A request that was urgent in the morning may be irrelevant by afternoon, so a person decides what to replay and what to close.
• Check for missed events. Providers that deliver notifications by webhook usually document retries and how to verify and re-fetch events, as in [Stripe's webhook documentation](https://docs.stripe.com/webhooks). Confirm your own integrations can catch up the same way.
• Re-run the golden test set, and check that memory and context are current, not frozen at the moment of failure.
• Step the agent back up one mode at a time, with a named person approving each step.
• Write a short note: cause, duration, what was handled manually, what changed in the plan.

Good records make this possible. If you cannot tell what the agent did and when, reconciliation becomes guesswork. AI agent observability: what should you actually log? lists the events worth keeping, and the [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) explains the underlying ideas of traces, metrics and logs.

How does a managed approach handle continuity?

In a Be Human engagement, fallback modes and manual procedures are defined alongside the agent's role, its tools, its approval boundaries and its success criterion, so the plan exists before the agent has authority. Managed operations include monitoring, integration maintenance, permission review and incident response, which means someone is watching for the failure shapes above and the runbook is kept current as tools and channels change. The company keeps control of the mode switches that affect its customers, and the agent's identity, memory and permissions stay under human oversight throughout.

Frequently asked questions

How often should we test the continuity plan? Test it on a schedule that matches how much the business depends on the agent, and again after any change to a model, tool, channel or permission. A short drill, where someone switches the agent to queue only and walks one manual procedure, is enough to find stale contact details and missing access. Record what failed in the drill and fix it before the next one.

Do we need a backup model for every agent? Not always. If the task can wait, a pause with a manual procedure may be safer and cheaper to maintain than a second model that behaves differently. Add a backup model when the task is time sensitive and you have tested the backup on real examples of that task.

Who should be allowed to pause the agent? Name at least two people with the authority and the access to do it, so one absence does not block the decision. The pause should be easy and should not need a technical explanation. Resuming should be a deliberate step that someone approves after the recovery checks.

What if the outage is in a channel such as Slack or email? Decide in advance where urgent alerts go when the main channel is down, and keep that route separate from the agent's own channel. The manual procedure should list the alternative contact path and the pre-approved message. After the channel returns, reconcile any messages sent during the gap before the agent resumes.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.