What should you do if your model provider goes down?

Fail safe first: stop agents cleanly so no action is left half done, and route their work to people. Switch to a second model only if it was certified for the same capabilities beforehand. When the provider returns, check the model version before restoring depth, because it may not be the model you certified.

Why is an outage a governance question, not just an IT one?

Because the obvious fix is the risky one. When a model stops responding, the quickest way to keep work flowing is to point the agent at another model. But an agent's certificate describes its behaviour with a particular model. A different model, even a good one, may refuse less, guess more or escalate differently. Switching in a hurry means running an uncertified agent at a depth it never earned, during an incident, when nobody is watching closely.

The decision about what to do in an outage should be made in calm conditions, written down and tested.

What are the options, and when does each fit?

Most organisations need the first option for every agent and the second only for a few. Certifying a fallback model costs a certification run every cycle; it is worth it where an outage would breach a customer commitment.

What are the steps during an outage?

1. Platform: stops the agent cleanly. Any task waiting on a model response is marked incomplete, not retried in a loop. Evidence: a filed verdict for each interrupted task.
2. On-call owner: confirms the outage and declares which option applies, from the runbook. Evidence: the declaration and time.
3. Operations lead: routes work to people or to the certified fallback. Evidence: the routing change.
4. Team lead: informs affected teams and, if needed, customers. Evidence: messages sent.
5. Analyst: lists tasks interrupted mid-way, such as a payment prepared but not submitted, so a person can finish or cancel each. Evidence: the list with outcomes.

What happens when the provider comes back?

Check before you restore. Providers sometimes return with an updated model, and an update can change behaviour in ways that matter, as model drift explains. If the version differs from the one certified, the agent stays at a lower depth until it is retested.

Then clear the backlog in stages. An agent catching up on hours of queued work at full speed can hit rate limits in connected systems or overwhelm the reviewers who handle its drafts.

What does that look like in practice?

Say a payments firm's agent screens incoming payment queries and drafts replies at depth 2, and also resolves simple status questions at depth 3. Its model provider goes down mid-morning.

The platform marks 14 in-flight tasks as interrupted. The on-call owner follows the runbook: status questions fail over to a second model certified at depth 2 only, so they become drafts for a person to send. Complex queries route to the payments support team. Two tasks had prepared a refund of a duplicate fee but not submitted it; a person completes one and cancels the other after checking.

The provider returns after three hours with the same version. The owner restores the original model and releases the backlog over the next hour. The following week the team reviews the incident and decides to certify the second model at depth 3 for status questions before the next cycle.

Which controls make outages survivable?

• An outage section in each agent's runbook, stating which option applies.
• Fallback models certified in advance, never improvised.
• Clean interruption, so no action is left half complete without a record.
• Version checks on return.
• Drills, as part of testing an AI agent before it goes live and at least yearly afterwards.
• A fast stop, as set out in shutting down an AI agent quickly.

The wider sequence is in our guide to deploying an AI agent.