Design AI workflows like access can break
AI access is a business dependency, and dependencies fail. Give every workflow a reduced mode that keeps running without the frontier model.
If your product depends on a model, your customers are depending on that model’s provider too. Losing it should cost you capability, not stop the work.
In June, Anthropic suspended Fable 5 and Mythos 5 globally after a U.S. government directive. Fable came back on July 1, but for a few weeks every workflow built on it had nothing to fall back on. Providers can also rate-limit, region-block, deprecate, reprice, or filter a model. If your plan for any of those is “wait for the vendor,” the workflow is fragile.
Most work doesn’t need the best model
A typical business workflow is a chain of small steps: read a document, classify it, extract fields, compare them to policy, flag exceptions, ask a person when unsure, keep an audit trail.
Classifying an invoice doesn’t take the strongest model available. It takes one that passes your evaluations for that task and that you can still run during an outage. That might be a smaller model, a private deployment, or something local. Save the frontier model for the work where its extra capability pays for itself: hard reasoning, difficult exceptions, advanced coding.
Give each model a job
Instead of asking which model runs the system, ask what each model is responsible for:
- Routine work and sensitive data run on local or private models.
- Hard reasoning and escalations go to a frontier model.
- A router sends each task by its requirements, not a hardcoded provider.
- Every provider, region, or model that can fail has a fallback.
- Saved evaluations show whether a model swap made things better or worse.
- Written rules decide what data can leave the company, the device, or the home.
- Policy decisions and irreversible actions go to a person.
In finance operations, that could mean a private model handles intake and extraction, a rules engine checks the known constraints, and the frontier model only sees redacted exceptions. At home, intent recognition and routine automation run locally and the cloud handles complex requests. The house shouldn’t stop working because an API is down.
Figure 01 · Illustrative
The same outage, three designs
A day of 100 invoices, 12 of them hard exceptions. When the frontier model goes down, one design stops, one buries the operations team, and one keeps doing routine work and queues only what needs the frontier model.
| Step | One provider for everything | Send everything to people | A model for each job |
|---|---|---|---|
| Read and classify | Frontier model: stopped | Operations team: by hand | Private model: running |
| Extract fields | Frontier model: stopped | Operations team: by hand | Private model: running |
| Check against policy | Frontier model: stopped | Operations team: by hand | Rules engine: running |
| Resolve hard exceptions | Frontier model: stopped | Operations team: by hand | Frontier model, redacted: queued |
| Decide policy calls | Person: nothing arrives | Operations team: behind | Person: waits on queued exceptions |
| Result with the frontier model down | 0 of 100 finished, 100 stuck | 20 of 100 finished, 80 backlogged | 88 of 100 finished, 12 queued |
Rehearse the outage
Before calling a workflow ready, turn off the primary provider, run a realistic workload, and watch what finishes, what queues, and what the operator sees.
Watch the humans as well as the software. A reduced mode that routes every case to an already busy operations team just moves the bottleneck. Someone should own the response, and there should be an agreed recovery time.
Continuity costs money, and so does an interruption: lost business, extra support, damaged trust. Some work can wait a day. For work that can’t, the price and the operating plan have to support what you promised the customer.