How do you handle an AI agent outage?

Fail closed, fall back, restore carefully. When an agent or anything it depends on goes down, nothing should execute without its checks. The team lead switches work to a manual fallback, someone secures any actions left half-done, and customers hear if they will notice. On restoration, the backlog is worked through in order, with approvals re-checked, before normal running resumes.

Is an outage the same as an incident?

No. An outage means the agent is unavailable or degraded: a model provider is down, a connection has failed, the platform is slow. An incident means the agent is working but doing something wrong. The responses differ. In an outage you replace the agent's work; in an incident you also have to find and fix what it already did. Incidents are covered in how to handle an AI agent incident.

Some outages turn into incidents. A degraded model can start producing poor answers rather than none, and an agent reading a broken data feed can act on wrong facts. If outputs look wrong rather than absent, treat it as an incident.

What does "fail closed" mean here?

If the checkpoint that applies the agent's bounds is unavailable, actions must stop, not proceed unchecked. If a source cannot be reached, the agent must not act on a cached copy beyond its freshness limit. If an approval system is down, held items stay held. Every dependency should be designed so that its failure stops action rather than removing a control.

What are the steps, and who does each?

Securing in-flight work is the step most often skipped. If the agent sent a payment instruction and the confirmation never came back, someone must check whether it went through before anything is retried. Writes that carry a unique reference make this safe; without one, a retry can duplicate the action.

Financial entities in the EU should also check whether the outage meets DORA's ICT incident reporting criteria, and decide in advance who makes that call.

How do you plan the manual fallback?

Before go-live. The fallback is the procedure people followed before the agent, kept current. It needs named staff who can step in, access they still hold, and a rough sense of capacity. To estimate how many people you need while the agent is down, use the manual average handle time for the work and the volume you expect.

Test the fallback at least once a year. A fallback nobody has used since the agent arrived is not a fallback.

What does this look like in practice?

Take a lender's operations team whose agent prepares direct debit collection files each morning. At 7 a.m. the model provider is unavailable. The agent produces nothing; the checkpoint blocks any partial file.

The operations lead declares an outage at 7.10. The team lead activates the fallback: two staff prepare the file using the old spreadsheet procedure. The operations lead finds one file from the previous evening's run marked as sent but unconfirmed, checks with the bank, and finds it was received. Nothing is retried.

The provider returns at 11. The agent does not produce the morning's file again, because people already sent it; the record shows the manual file. The afternoon run goes through the agent at a controlled rate, and the review notes that the provider's status page was the first sign. Monitoring is changed to check it directly.

Which controls make outages manageable?

• Fail closed on every dependency.
• A current manual fallback with named people.
• Unique references on writes, so in-flight actions can be checked and retries are safe.
• Freshness limits on cached data.
• Controlled backlog processing after restoration, with approvals re-checked.
• Input monitoring, because broken upstream data can look like an outage; see handling data quality problems for AI agents.

Fallback planning is part of getting ready for production; see deploying an AI agent: train, shadow, certify, widen.