Availability is inherited
Your AI employee depends on a model provider, your own systems, and whatever integrations connect them. Its effective availability is the product of all of those, which is always lower than any one of them.
Decide the fallback explicitly
Queue the work for a human, degrade to a simple acknowledgement, or say plainly that it is unavailable. The unacceptable option is silence, which is what you get by default when nobody chose — the reason failure states deserve design.
An outage that returns nothing looks identical to a business that ignores its customers.
Customer-facing needs a louder fallback
Internal drafting can simply pause. A customer waiting on a reply cannot be left with nothing, so the front door needs the most robust degradation path even though it is the least likely thing to be built.
Alarm on absence, not just on errors
The dangerous failure is the quiet one — a queue that stopped processing rather than a request that errored. Monitor for work not happening, which is the same invisible-failure problem that makes a system production-ready or not.
Nothing may be lost
Every enquiry that arrives during an outage must be recoverable afterwards, even if it wasn’t answered. This is exactly why a form should record the submission even when the notification path fails.
Tell the team it happened
The people covering for it need to know, and the queue that built up needs working through deliberately. An outage nobody was told about becomes a backlog nobody clears.