Design the Fallback Before the Model Fails You
The model will fail, time out, or return garbage. AI-native failure design means building the fallback path first, so a bad model call degrades instead of breaking.
Design the failure path before you design the happy path. The model will time out. It will return malformed JSON. It will produce a confident answer that is wrong, or refuse a request it should have handled. This is not an edge case you can defer, it is the base rate of working with a probabilistic system over a network. An AI-native product decides, up front, what the user sees when the model call goes bad. A bolted-on one lets the exception bubble up as a spinner that never resolves or a stack trace in the console.
The thesis: in AI-native software, the fallback is a first-class part of the design, and a feature without a defined failure path is not finished.
Why AI features fail more than normal features
A normal function call fails rarely and usually loudly. A model call fails in more ways and often quietly. It can be slow past your timeout, hit a rate limit, return output that does not parse, return output that parses but is wrong, or refuse. Some of these are visible errors you can catch. The dangerous ones are the plausible-but-wrong answers that pass every technical check and still ruin a downstream step. This wider, quieter failure surface is exactly why AI agents fail in production at rates that surprise teams used to deterministic code.
So you cannot treat the model call as "returns or throws." You have to treat it as "returns good, returns bad-but-parseable, returns unparseable, times out, or refuses," and design a response for each.
How to design the fallback path
Start with the question: what is the safest thing to show when we do not have a good answer.
Degrade to a simpler mode. If the smart summary fails, show the raw text. If the AI categorization fails, leave the field blank and flag it for the user rather than guessing. A partial, honest result beats a fabricated complete one. This often means keeping a deterministic path to fall back to when the model is unavailable or unsure.
Validate before you trust. Parse and schema-check every structured output. If it does not conform, that is a failure, catch it and retry or fall back. Do not render half-broken JSON and hope. Pairing validation with guardrails built into the product is what turns a garbage response into a caught error instead of a corrupted record.
Set a real timeout and a retry budget. Decide how long you wait and how many times you retry before you give up gracefully. An unbounded wait is not patience, it is a hung UI.
Make failure visible and recoverable. Tell the user plainly that the AI step did not complete, and give them a path forward: retry, edit manually, or proceed without it. Silent failure is the worst outcome because the user acts on missing or wrong data without knowing.
When to fail closed versus fail open
This is the judgment call. Fail open means proceed without the AI step. Fail closed means stop and require a human.
Fail open when the AI is an enhancement and the base flow works without it. A missing smart-reply suggestion should not block sending an email. Degrade and move on.
Fail closed when the AI output feeds an irreversible or high-stakes action. In AI-native case management or bookkeeping, a failed extraction should never silently write a wrong value into a filing. Stop, flag, escalate. The cost of a quiet error there is far higher than the cost of a pause.
Getting this call right per feature is the core of AI-native failure design. It is not a global setting, it is a decision you make for each place the model touches real consequences.
The rule I hold products to
Every model call in the product has a defined answer to "what happens when this fails." Not caught by a generic error boundary, defined: what degrades, what retries, what escalates, what the user sees. If a feature does not have that, it is not done, no matter how good the demo looked.
We design the fallback first across the automation surfaces at Girard AI, because the demo runs on the happy path and production runs on all the others. Build for the failure and the success takes care of itself. Build only for the success and your users become your error handlers.