An AI integration depends on more than the model. Retrieval, authentication and connected tools can fail independently. When buying an automation workflow, ask what the user can still accomplish if one dependency is unavailable. A useful fallback is an agreed operating mode, not a generic error message or an untested provider switch.
Related service: AI automation development- 01Detect the failed capability
- 02Stop unhelpful retries
- 03Offer the agreed fallback
- 04Recover and reconcile
SECTION 01
Choose alternatives by task
For public FAQs, a link to maintained help content may be adequate. For document extraction, retaining the upload in a visible queue may work better. For an account-changing action, the safe path may be to pause and ask an operator. Define the fallback for each capability instead of treating the whole assistant as one switch.
Microsoft's circuit-breaker guidance distinguishes repeated transient retries from stopping calls likely to keep failing. Ask the agency to configure retry limits and recovery checks around the selected dependency. A fallback model also needs acceptance tests, approved data handling and compatible output validation; it is not merely a different endpoint.
SECTION 02
Illustrative example: unavailable order lookup
A customer asks a store assistant for an order's current status. The approved order system is unavailable, although the language model is working. The assistant can explain the temporary lookup problem and provide the normal support route. It must not turn a general shipping policy into a claimed status for that order.
If the customer chooses a callback request, the application confirms whether that request was actually recorded. When the order system returns, the operator can resume the request using its reference. This hypothetical example separates conversational availability from the availability of authoritative business data.
SECTION 03
Ask for an outage rehearsal
Test connection failure, provider throttling, a slow response and invalid credentials separately. Show what the visitor sees, where the unfinished work lives and who receives an alert. Verify that a large backlog does not immediately overwhelm a recovering dependency or repeat already completed actions.
Microsoft's retry pattern highlights the need to consider side effects. Handoff should include fallback rules, operational owners, queue limits and a recovery checklist. More fallback infrastructure increases testing and maintenance. A clear manual route can be a better initial choice than several automatic alternatives whose behavior and data handling have not been reviewed.
SECTION 04
Frequently asked questions
Should we always add a second AI provider?
No. Compare the need for continuity with the extra evaluation, data handling and operational work. A non-AI fallback may fit the task better.
Can an old cached answer be used?
Only where its freshness and access scope remain acceptable. Label relevant limitations and never substitute cached private data across users.
Does a retry mean the task failed?
Not necessarily. A lost response can leave the outcome uncertain, so check execution evidence before repeating a consequential action.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Circuit Breaker patternMicrosoft Learn
- Retry patternMicrosoft Learn
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy