Quick answerOnce an outage is declared internally, switch the agent out of its normal troubleshooting flow and into a short, honest acknowledgment mode: confirm the customer is not alone, state what is known, point to the status page, and stop asking them to retry steps that will not work anyway. Running individual troubleshooting during a declared outage wastes the customer's time and reads as either incompetence or denial. This is a different problem from a model provider outage, where the fix is failover to another provider; here the company's own product is down, so there is no failover, only honest communication until the fix ships.
Detect the mode switch, do not rely on the customer to trigger it
The agent needs a live signal, not a guess based on error patterns in one conversation, that a declared outage is in effect. Wire the agent to an internal incident flag, the same one that presumably updates a public status page, so every conversation started while the flag is set gets outage-mode behavior automatically. Without this wiring, the agent keeps running its normal decision tree, asking a customer to clear cache or check their connection during an outage every other customer is also hitting, which is precisely the behavior that turns a bad day into a public complaint. If you do not yet have a dedicated status surface for this, a dedicated status or uptime page for the AI agent is the natural place to source that same flag from.
What outage mode should actually say
Outage-mode responses should be short, specific about what is and is not known, and free of individual troubleshooting steps that only make sense for an isolated problem. Tell the customer this is affecting other users, give the honest current status rather than an optimistic estimate the team cannot back up, and set a channel for updates rather than promising the agent itself will follow up (it will not remember this conversation later unless that is explicitly built in). Once the incident resolves, the follow-up communication is a separate, already-covered problem; see what a company should communicate to customers after an AI agent has a production incident for the after-the-fact side of this, since outage-mode conversation design and postmortem communication solve two different moments.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
Where the line sits between a full outage and a bad individual experience
Not every reported issue during a partial degradation deserves full outage-mode language, and treating every complaint that way during a rocky period erodes trust the same way ignoring a real outage does. The related question of exactly when a partial slowdown crosses into an outage-severity response is its own decision, covered in when slower and worse should trigger the same response as down; use that threshold to decide when to flip the flag, then let this post's conversational design take over once it is flipped. The two problems are sequential, not the same one: first decide it is an outage, then decide how the agent should talk during it.
FAQ
Should the agent still try any troubleshooting during a declared outage? Only for problems clearly unrelated to the outage's known scope. If a customer's issue matches the incident's signature, skip troubleshooting entirely and go straight to acknowledgment; mixing the two makes the agent look like it has not registered that anything is wrong.
Should the agent apologize on the company's behalf during an active outage? A brief, sincere acknowledgment is appropriate; an elaborate apology before the cause or fix is known can commit the company to language that ages badly once more is known. Keep it short and factual.
What happens if the outage flag is wrong or stale? Treat a stuck outage flag as its own incident. An agent stuck in outage mode after service is restored is just as damaging as one that never switched into it, so the flag needs the same monitoring and alerting as any other production dependency.