Here is a question worth asking about any AI feature before it ships: what does the product do when the model is not available?
The answers people give fall into three groups. Some say the feature shows an error. Some say they had not thought about it. A few say the feature still works, just less impressively — and those are the ones whose products survive contact with an enterprise procurement process.
Because the model will be unavailable. Not often, but on a long enough timeline: an outage, an expired key, a rate limit at month-end, a network path that a security team closed on Tuesday, a customer whose policy forbids sending data to a third party at all. If any of those turns your product into a blank screen, you have not built an AI feature. You have built a dependency.
The swap seat
The structural fix is small and worth doing early: everything the application knows about interpreting a user’s request should live behind a single function. One signature, one place where the decision about which implementation runs is made.
Behind that seat you can put a hosted frontier model — Claude, in our case, which is what the assistant runs on by default. You can put a smaller local one. You can put a deterministic parser that recognises a fixed set of phrases. The rest of the application cannot tell the difference, because the rest of the application never had a reference to the model in the first place.
This is not a novel idea — it is dependency inversion applied to something people forget to apply it to. But LLM integrations resist it in a specific way. Model calls tend to sprawl: a prompt here, a streaming handler there, a retry in a third place, an SDK type leaking into a component signature. Once that has happened, the seat does not exist any more, and building a fallback means an archaeology project.
What a good fallback looks like
The fallback does not have to be as capable. It has to be honest and useful.
In our flow builder, the assistant’s job is to translate a request into commands against a named tool surface — add a step, connect two steps, set a variable, validate. With a model behind the seat it handles arbitrary phrasing and multi-step requests. With the deterministic parser behind it, it handles a narrower set of phrasings and does exactly the same thing to the flow.
Three properties make that acceptable rather than embarrassing:
The same command surface. Both implementations produce calls to the same schema’d commands. The fallback is not a different feature; it is a less flexible driver of an identical mechanism. Nothing downstream branches on which one ran.
Honest about mode. The interface says which mode it is in and what that means. Users tolerate reduced capability remarkably well when it is stated. What they do not tolerate is a feature that silently gets worse.
A path to full capability. If the reason is a missing key, say so and offer to take one. Do not make the user infer that a configuration step exists.
The commercial argument
There is a business case here that is easy to miss while thinking about outages.
You can demo without exposing a key. A public interactive demo needs no embedded credential, no proxy, no rate-limit exposure, and no risk of somebody scraping the key. It runs the fallback, and every visitor gets a working product rather than a video.
You can sell to customers who cannot use hosted models. Some organisations genuinely cannot send process data to a third-party API, and no amount of explaining the data-handling terms will change that this quarter. A product with a swap seat has an answer — a local model, or the deterministic path — instead of an apology.
You are not repricing your product every time a vendor reprices theirs. If the model is one implementation behind a seat, changing it is a configuration decision.
What this is not
This is not an argument for treating models as interchangeable commodities. They are not, and the gap between a capable model and a keyword parser is enormous — that gap is exactly why the AI path is the default and the fallback is the fallback.
It is also not an argument for the lowest common denominator. Do not cripple the model path so both modes behave identically. Let the good path be as good as it can be; let the other path be honest about being narrower.
The point is narrower than either: know where the seat is. Most teams discover they do not have one at the worst possible moment — during a security review, or a procurement questionnaire, or an outage. Building it costs an afternoon at the start of a project and is very expensive to retrofit.
EFTEDRA is an Anthropic practice — we build on Claude, and we build so that the surrounding product stays sound when the model is unreachable. Talk to us.
And there is a quieter benefit. A feature that can run without the model is a feature you can test deterministically. The fallback path doubles as a test fixture, which means the surrounding logic — the commands, the validation, the undo — has a fast, free, repeatable way to be exercised in CI. That alone tends to pay for the seat.
Building the seat before you need it
The seat is cheap at the start and expensive to retrofit, so it is worth knowing exactly what it looks like.
It is one function. Everything the application knows about interpreting a request goes through it, and its signature contains no vendor types — no SDK message objects, no provider-specific streaming handles. Inputs are your own types; outputs are calls against your own command surface.
The discipline that keeps it a seat rather than a formality: no SDK import outside the implementation file. The moment a provider type appears in a component signature, a store, or a test helper, the seat has stopped existing and nobody noticed. This is worth enforcing with a lint rule, because it erodes through ordinary, reasonable changes rather than through anybody deciding to break it.
How good does the fallback have to be?
The honest answer is: good enough to be useful for the most common request, and honest about everything else.
A deterministic parser handling a dozen phrasings of the five most common operations covers a surprising share of real use, because usage is heavily skewed — most requests are simple, and the long tail is long but thin. What it must not do is fail silently or pretend to have understood. “I can do that in full mode — here is how to enable it, or you can do it directly on the canvas” is a good failure. Doing nothing, or doing the wrong thing confidently, is not.
There is a second useful fallback tier worth considering: a smaller local model. It sits between the frontier model and the parser — more capable than pattern matching, no external dependency. Whether it is worth the operational weight depends entirely on whether your buyers include organisations that cannot use hosted APIs at all.
What this looks like in procurement
The commercial payoff shows up in specific questions, and having a structural answer changes the conversation.
| Question | Answer with a seat |
|---|---|
| What happens if the AI provider has an outage? | The feature degrades to a deterministic mode. Nothing in the product stops. |
| Can we run this without sending data to a third party? | Yes, at reduced capability — and here is precisely what is lost. |
| What if you change model providers? | One implementation file. No change to the product surface or your processes. |
| How do we test this deterministically? | The offline path is the test fixture; the suite runs without network or credentials. |
None of these require a promise about uptime, pricing or roadmap — which is fortunate, because those are the promises you cannot make.
The failure mode to avoid
There is a way to get this wrong that looks like getting it right: building the seat, then letting the two implementations drift until they are different features.
It happens gradually. The AI path gains a capability the offline path cannot express. A caller starts branching on which mode is active. Six months later the offline path is a vestigial code path nobody tests, and it fails the first time it is genuinely needed — during the outage, in front of the customer who asked about outages.
Two habits prevent it. Run the same contract tests against both implementations, so a capability that exists in one and not the other shows up as a failing test rather than a silent divergence. And keep callers ignorant of the mode — if any code outside the seat asks which implementation is running, the abstraction has already leaked.
EFTEDRA builds workflow automation on IBM Business Automation Workflow and Claude — assistant tasks and coach views that install into the processes you already run. See what we build, or try the live demo.