Your AI works. Until the connection fails.

An outage exposes dependencies

On 29 September 2026, OpenAI reported elevated error rates across ChatGPT, Codex and its API. The incident page also contains a recovery update dated 6 October. This is a timely reason to examine our own dependencies; it does not establish that every customer experienced a week of downtime. [1]

An AI demonstration usually shows what happens when everything works. A useful business process must also account for answers that arrive late, stop halfway through or never arrive. Which tasks can continue? What information is preserved? Who takes over? These questions belong in the design, before the first user gets stuck.

Start with the task that needs to continue

Consider a fictional example: an employee asks AI to summarise a customer question and prepare a draft response. The employee reviews the proposal and sends the answer. This is a design scenario, not an account of an SBIT client project.

If AI becomes unavailable, the customer question need not disappear. Preserve the original input, show that the draft is unavailable and offer manual processing. Agree with the Product Owner and users what interruption is acceptable. A writing suggestion might wait; a time-sensitive application may need a different route.

Define that agreement as observable behaviour. For example: when the agreed waiting time expires, the input remains available, a clear message appears and an employee can continue. Choose that deadline from the needs of the process and measurements, rather than an arbitrary round number.

Retries need a boundary

A temporary failure may justify another attempt. Microsoft describes bounded retries with appropriate delays and warns that aggressive repetition can further overload a struggling service. Not every failure is temporary: an invalid request needs correction. [2]

Set a total budget for waiting and retrying. Check which retries the client library already performs. Otherwise, apparently modest settings at several layers can combine into many more requests.

For persistent failures, a circuit breaker can temporarily block new calls and later allow limited attempts to check recovery. This can protect the rest of the application from a failing dependency. It is a possible design choice, not a mandatory part of every AI integration. [3]

No response does not mean nothing happened

Recovery becomes more sensitive when an AI workflow also performs actions. Suppose a downstream step creates a ticket but its acknowledgement is lost. Blind repetition could create two tickets. AWS explains how an agreed unique request identifier helps handle repeated commands without additional side effects. [4]

Sending a key is insufficient on its own: the receiving service must support that behaviour. When the outcome is unknown, investigate the processing status first. Also separate generating an AI proposal from executing a business action. Never silently treat an interrupted text stream as a complete, approved result.

Test interruption and recovery

Do not wait for a real provider outage to run these checks. Simulate failures at the integration boundary in a test environment. Combine fast, repeatable checks with limited integration tests against the real service. The scenarios below are a proposed starting set; select and deepen them according to your risks.

1. No response: let the maximum waiting time expire. Check preservation of input, messaging, bounded attempts and the next step offered to the user.
2. Interrupted response: stop the stream after several text fragments. Check that the result is treated as incomplete and does not trigger a downstream action.
3. Unknown action outcome: execute the action but suppress its acknowledgement. Check that recovery does not cause a second business operation.
4. Recovery after an outage: restore the service after an employee has continued manually. Check that a late AI result does not overwrite their work.
5. Handover under pressure: submit several interrupted tasks. Check ownership, visibility of the queue and the information provided to the employee.

Make human handover workable

“A person will review it” becomes a workable agreement only when it specifies who, when and with what information. Show the original question, completed steps, uncertain outcome and reason for handover. Give employees a way to complete the task without automation simultaneously continuing it.

Switching to another model may be an option, but requires its own assessment of response quality, data handling and behaviour. Do not assume that the substitute is equivalent. Explicitly waiting or processing a task manually can sometimes be the more controllable choice.

Discuss this before the next release

Choose one important AI process and walk through the failure scenarios with development, operations, Quality Engineering and a user. Record who monitors outstanding tasks and what evidence counts as successful recovery. Look beyond technical error messages to unfinished work and duplicate processing.

For SBIT, quality starts with these agreements: which risk are we controlling, and what feedback helps us decide? A reliable AI application provides a useful answer and a clear, tested route when that answer is unavailable.