Most AI agents depend on three things the business does not fully control: a model, often running in someone else's data centre; a connection to reach it; and power at your end to keep everything on. Any one of them can fail for an afternoon. Load-shedding, a cut fibre line or an outage at the model provider will each do it.

When that happens to a person, everyone knows what to do. They phone, they write it down, they catch up later. When it happens to an AI agent, the usual answer is that nobody decided. Work stops halfway, a queue fills without anyone noticing, or a fallback nobody tested starts doing the work on its own.

This piece is for the chief information officer (CIO) or Head of IT who will put AI agents into live operations, and who will be the first person called when they stop.

Why outages hurt more once AI agents do the work

  1. The backlog has no owner. When a person handles intake, a lost afternoon becomes a pile they remember. When an agent handles it, the pile sits in a queue nobody is watching.
  2. Half-done is worse than not started. An agent that loses its model in the middle of a change can leave an order updated in one system and not in the other.
  3. Silence looks like success. If an agent stops without saying so, customers are often the first to find out.
  4. The fallback can be the risk. A quick switch to another model, or to a rule nobody reviewed, keeps work moving while quietly lowering its standard.

The rule: every agent has a written outage mode

For each job an AI agent does, the business decides in advance what happens when the agent cannot work normally. There are three honest choices.

  1. Pause and hold. The agent stops taking new work, finishes or reverses the step it is on, and keeps every waiting case in order until it is back.
  2. Hand back to people. The work goes to a named team, with what they need to do it by hand. The agent picks up from where they left off.
  3. Carry on at a lower level. The agent keeps doing the simplest, lowest-risk part of the job, such as logging and acknowledging enquiries. Anything that needs judgement waits.

Which one fits depends on the job. Acknowledging a customer email can carry on. Approving a payment should pause. What matters is that a person chose the mode, wrote it down, and can see when it is in force.

What good looks like

This is the design in plain terms, not a build manual.

  • Each job has its outage mode on record, with a named owner, alongside the agent's other rules.
  • Nothing is lost. Work that arrives during an outage is kept in order and picked up when the agent is back.
  • Steps finish cleanly or not at all. Each job says whether a step in progress completes or is reversed, so records never disagree with each other.
  • People are told, inside and outside. Staff can see which agents are paused. Customers who are waiting are told what to expect, in plain words.
  • A fallback model meets the same bar. If the business keeps a second model, including a smaller one on its own hardware, that model is tested on the same real cases as the first. It gets only the jobs it passed.
  • Recovery is a step, not an assumption. When the agent comes back, a person checks the backlog, the half-finished cases and anything staff did by hand in the meantime.
  • Every outage leaves a record. What stopped, for how long, which mode applied, and what was caught up afterwards.

Where this gets harder than it sounds

Not every dependency is obvious. One agent may rely on a model, a search index, a mailbox, a supplier's system and the network. Any of them can be the part that fails. List them for each job before you need the list.

Backup power is not a working agent. A generator or battery can keep the office lit while the line to the model provider is down. Test the whole path, not only the lights.

Manual mode needs practice. If staff have not done a job by hand since an agent took it over, the hand-back mode only works on paper. Rehearse it on a quiet day.

Catching up has its own risk. An agent that returns to a long queue can act on information that changed while it was away. Before it acts, it rechecks anything time-sensitive, such as stock, a price or the customer's latest message.

Short drops hide. Repeated short interruptions can do more harm than one long one, because nobody declares an outage. Decide what counts as one, and let the agent change mode on that rule.

Five questions to ask before an AI agent goes live

  1. For this job, what does the agent do if it cannot reach its model, and who decided?
  2. Where does work wait during an outage, and who can see that queue?
  3. If the agent stops in the middle of a step, does the step finish or reverse?
  4. Who tells staff and customers that the agent is paused, and in what words?
  5. When the agent comes back, who checks what happened while it was gone?

If nobody can answer the first question, the first outage will answer it for you.

Running AI agents includes the bad days

Building an AI agent is the visible part. Running it means planning for the afternoon when the model, the line or the power is not there. Write the outage mode for every job, rehearse it, and record what happens. Then an outage becomes a delay the business planned for, not a mess it discovers later.

Futuvara is a creative technology agency. We build, implement and run AI platforms for our partners. If you are planning how your AI agents should behave when something they depend on goes down, start a conversation.

Start an Agentic conversation →

Sources: