In this insight
When an AI API fails, the first priority is preserving the work the user entrusted to the application. A failed attempt to summarize, analyze or generate something should not quietly erase the original input or leave the person guessing whether it was saved.
This requires more than an error message. The application must distinguish the user's record, the processing attempt and any action that follows. Those are separate facts, and they may succeed or fail independently.
Save the work before depending on the enrichment
Imagine a fictional team submitting a maintenance request. The description is useful on its own. AI may help categorize it or suggest follow-up questions, but an unavailable model should not make the request disappear.
A useful design records the request durably, then tracks the analysis as a separate job. The interface can say request saved, analysis waiting. That is more truthful than showing one spinner until both operations succeed and then treating any failure as a total loss.
This is a design pattern, not a rule that every action should be queued. Some tasks require immediate validation before a record can be accepted. Define that boundary explicitly. The important question is which part represents the user's work and which part is additional processing.
Treat a retry as another attempt, not another request
A person presses Try again after a timeout. Are they creating another maintenance request, or asking the system to analyze the existing one? If the software does not distinguish these intentions, recovery can produce duplicate work.
Give the durable request an identity and link processing attempts to it. Keep the outcome of each attempt so that an operator can understand what happened. A retry should continue the intended operation under its defined rules, not silently rebuild the whole workflow from scratch.
Engineers call an operation idempotent when repeating it has the same intended effect as doing it once. That does not mean every request returns identical text or that an AI model becomes deterministic. It means the surrounding business action, such as creating one request, is protected against unintended repetition.
A timeout does not prove nothing happened
An outside service may finish an action while the response back to your application is lost. If the application assumes failure and sends the action again, it can create a duplicate. This is especially important for messages, calendar entries, orders or other external effects.
Before retrying such work, determine whether the earlier operation can be identified or its result checked. Where the receiving system supports a stable request identifier, use its documented behaviour. Where it does not, design a reconciliation path rather than claiming a universal exactly-once guarantee.
Do not mix these concerns with retrying a harmless read. Fetching a status again and sending another invitation can have very different consequences. Recovery policy should match the operation, not merely the fact that both use an API.
Make cancellation and newer versions meaningful
Suppose the maintenance request is withdrawn while analysis is waiting. The worker should not later present a fresh recommendation as though the request were still active. Cancellation must affect the eligibility of the next action, even if some processing cannot be interrupted immediately.
A revised request creates a similar problem. If analysis started on version one and the person now submits version two, the older answer should not overwrite the newer work. Associate results with the version they analyzed and make stale results visible as stale.
Check current access before delivering sensitive output. A user entitled to start a job may lose access before it completes. Durable processing is not a reason to preserve delivery rights indefinitely. The application needs a clear policy for ownership and access at each meaningful boundary.
Design a recovery screen that tells the truth
Useful states include saved, waiting, processing, needs attention, cancelled and completed. Each should have a precise meaning. A person should know whether to wait, correct input, retry or contact someone.
Give support staff enough information to investigate without exposing private content in general logs. A job identifier, attempt status and safe error category may be more useful than a copied prompt full of customer material.
Then test recovery deliberately. Stop a worker after the request is saved, simulate a timeout and reopen the browser. The application should find the existing work and explain its status. Returning a reassuring message without verifying persistence only moves the uncertainty from the developer to the user.
Model conversion exercise
Use this exercise with a real workflow and the people accountable for its outcome. Record disagreements as modeling questions instead of silently choosing an answer.
Map a fictional request through saving, AI analysis and notification. For each step, write what is durable and what can be repeated safely. Then walk through a timeout, a second click, cancellation, a newer version and access removal. Describe what the user should see and which side effects must not happen again. Use a controlled test environment, not live customer deliveries.