Solution · AI Operations
Your AI provider is going to go down. The question isn't whether — it's what your operation does for that half hour.
Monitoring tells you something is failing. Availability is what keeps the work shipping while it fails: a second path, a degraded mode, queues that absorb the hit and a recovery target agreed per use case. We build that function and we run it.
The problem
You're treating an outside supplier like a constant in your architecture.
- If your model provider has a bad half hour, you have a bad half hour. There's no second path and nobody has ever tested whether there could be.
- Every agent talks to the same provider, with the same key, against the same quota. A spike in the marketing agent burns the limit of the agent that bills.
- When the model returns an error, the process doesn't degrade: it stops. No partial answer, no queue, no «we'll have this sorted in ten minutes»: there's a blank screen and a customer waiting.
- Retries, where they exist, are instant and in a loop. When the provider is saturated, your system adds load and stretches out its own outage.
- Nobody has written down how long each use case can be down. The website chat and the system that issues invoices get treated the same, and they're nowhere near equally valuable.
- You know there was an incident because a customer mentioned it or because somebody happened to look at the provider's status page. The alert came from outside.
- The plan for a long outage lives in one person's head. If the outage lands on a Friday night and that person is on vacation, the plan doesn't exist.
Cost of staying the same
You've put an outside supplier whose status you don't control into the critical path of your operation, and you've done it with no plan B, no limits and no internal agreement on how long things can stop. That gets paid for three ways. The first is direct: every incident at the provider is an incident of yours, with its backlog of late work and its angry customer. The second is worse because it's invisible: with no isolation and no quota control, a small problem in a secondary system takes out a critical one, and the diagnosis costs hours. And the third is credibility: when leadership asks how long this can be down, the honest answer today is «we don't know», and that answer is what stalls the next AI project.
The solution
We build continuity as a function: a second path, controlled degradation and an agreed target per use case
- 1We start with the agreement, not the architecture: which use cases are in production, how long each one can be down without real damage, and what happens meanwhile. That target gets signed off with the business, not decided by IT alone, because it's a decision about risk and about cost — high availability is something you pay for.
- 2We build the second path. An alternative provider or an alternative model for the cases that justify it, with the routing prepared and tested, not drawn on a diagram. The secondary path may deliver worse quality: that gets measured up front and you decide whether it's worth it, instead of finding out on the day of the outage.
- 3We define controlled degradation, which is the piece almost nobody has. What the system does when the AI isn't available: answer with the deterministic part, queue the work and state the timeframe, hand off to the person on call, or return an honest answer. Anything before the blank screen.
- 4We put limits and queues in with judgment. Separate quota and keys per system so one spike doesn't eat another's budget, retries with growing backoff instead of loops that make the provider's outage worse, and a queue that absorbs the hit and reprocesses when service returns without losing work along the way.
- 5We isolate failures. An agent that gets stuck shouldn't block the whole process: circuit breakers per dependency, maximum times per call, and separation of the critical from the incidental, so the outage is one piece and not the system.
- 6And we run it. Watching your providers' status, wired into your own alerting; an on-call rotation with an incident playbook — who decides to switch paths, when it degrades, how it gets communicated — and a regular drill: we take it down on purpose and time the recovery. A plan that has never been executed isn't a plan.
What changes
What you stop losing
The major model providers publish a public status page with incident history and scheduled maintenance. The data exists and you can look it up; what's missing at almost every company is that data feeding into their own alerting instead of being checked by hand once something already went wrong.
Providers' public status pages (e.g. status.claude.com), accessed 2026-08
Providers' enterprise service level agreements compensate you with credits, not with continuity: you get part of the invoice back, not the hours your operation spent stopped. Continuity is something you have to build on your side.
Mechanism · standard SLA terms with credits
The outage stops being binary. With degradation defined, the system goes from «it doesn't work» to «it works worse and says so», which is the difference between an incident and a crisis.
Mechanism
Budget and quota stop being a common resource with no owner: every system has its own key and its own limit, so a spike in the incidental no longer consumes the capacity of the critical.
Mechanism
What we measure: real availability per use case (not the provider's), detection time and recovery time as timed in drills, % of requests served by the secondary path during an incident, work queued and reprocessed with no loss, and quota consumption per system against its limit.
What we measure
Spec sheet
- Work it removes
- an AI provider outage being an improvised crisis — no second path, no degraded mode and nobody who knows how long you can be stopped — and the alert arriving through a customer instead of through your own system
- Typical setup
- 4–8 weeks
- Input
- your AI systems in production, their provider and model dependencies, your queues and your current incident process
- Output
- an agreed recovery target per use case, a tested second path, degradation defined instead of a blank screen, queues with retries and per-system quota, failure isolation, and an on-call rotation with a playbook and rehearsed incidents
- Works with
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralInngestTemporalDatadogPagerDuty
- Can connect to
- Your current model providers, without replacing any of themYour model gateway or router, if you already have oneYour message queue and your retry layerYour observability, your alerting and your on-call exactly as they work today
- What we measure
- real availability per use case, not the provider'sdetection time and recovery time as timed in drills% of requests served by the secondary path during an incidentwork queued and reprocessed with no loss after an outagequota consumption per system against its limit
- Good fit for
- companies with AI already in the critical path of a real operation — support, billing, logistics, back office — where the CIO, the COO or the head of AI has to answer how long this can be down and today can't
- Not a fit for
- anyone running an internal pilot with no users and no consequences — high availability there is spend with no return, and we say so before we start — or anyone looking to switch model provider on quality or cost: that's [choosing and switching models in production](/soluciones/elegir-y-cambiar-de-modelo-de-ia-en-produccion), a different function
Frequently asked questions
Monitoring answers «what's happening?» and availability answers «and meanwhile, what?». Monitoring instruments, measures and alerts: it's the detection layer, and it's covered in monitor AI in production. Without it you don't find out, so it's the prerequisite. But an alert doesn't keep the work shipping: that's what the second path, the degraded mode, the queue that absorbs the hit and the agreed recovery target do. You can have an immaculate dashboard and an operation stopped for half an hour, watching it turn red in real time. The practical rule: monitoring tells you when to act; availability decides what happens if you don't act in time.
No, and it's worth reading what that SLA actually buys. Providers' service level agreements compensate you with credits against the invoice when they miss the target: you get money back, you don't get back the hours your operation was stopped or the customers who left. On top of that, the target is measured against the provider's service, not against your use case: if your process depends on three chained calls plus a database, your real availability is worse than any of those pieces on its own, and no contract covers that. An SLA is a commercial guarantee; continuity is an architecture decision taken on your side. What we do with the SLA is use it: its targets and its advance notices feed into the calculation of what needs a second path and what doesn't.
Yes, which is why you don't double up on everything. Redundancy applies only where the target agreed with the business justifies it, and that agreement is the first step precisely so you don't end up paying for high availability on the internal HR chat. At most of the companies we work with, one or two use cases justify a second path and the rest gets solved far more cheaply: with well-defined degradation and a queue that reprocesses when service returns. The cost that is fixed is the discipline — separate keys and quotas, maximum times, circuit breakers — and that gets paid once and avoids the most expensive class of incident there is: the one that starts small in a system that doesn't matter and ends up taking down the one that bills.
Whatever we decided beforehand for that use case, and that's the important part of the answer: it gets decided in advance, not in the heat of the moment. The four modes that cover almost everything are: switch to the secondary path automatically when the quality drop is acceptable; answer with the deterministic part of the process and hold only what needs the model; queue the work with a timeframe communicated to the user and reprocess it in full when service returns; or escalate to the person on call if the case is critical and can't wait. Every use case has its own written down, with who activates it and how it gets communicated. And it gets rehearsed: we take it down on purpose on an agreed cadence and time the recovery, because a playbook nobody has executed is a document, not a capability.
We run it, because availability isn't a deliverable: it's a function that degrades on its own if nobody holds it up. You add an agent and somebody has to decide whether it's in scope; the provider changes its rate limits and the quotas need readjusting; a new model ships and the secondary path from six months ago is no longer the best option; the on-call rotation gets reshuffled and the playbook is left with names that aren't there any more. The build part is the initial four to eight weeks; what follows is the on-call, maintaining the paths, watching your providers' status and the regular drill. If you'd rather your team ran it, we build it, we document it and we train your people — and we say so plainly in the proposal, without tying you to us by design. The rest of the catalog for this function is at AI Operations.
Want it running in your business?
You’ve pinned the problem. We ship the fix and leave it measured.