Your AI Vendor's Next Outage Tests More Than Uptime

Anthropic reported elevated errors across Claude models on August 5, 2026. The incident was resolved later that day, but the important lesson is not that an AI provider had an outage. Every major cloud service has outages. The lesson is that an AI-dependent workflow can fail in several ways before anyone notices.

A customer call can go unanswered. A job can remain unassigned. A dispatch request can disappear between systems. A technician can receive incomplete instructions. By the time someone sees an error dashboard, the operational damage may already be real.

For local service businesses, the right question is not whether an AI model occasionally fails. It is whether the surrounding workflow can detect the failure, preserve the job context, and recover without dropping a customer or breaking a field commitment.

Uptime Is Only the First Metric

Most AI vendor evaluations begin and end with availability. That is understandable, but incomplete. A vendor can report excellent uptime while your business still experiences failed calls or delayed dispatches because the model response timed out, a tool call failed, or an integration accepted a request without completing the underlying action.

Think of the workflow as a chain:

• A customer calls.
• The system identifies the request.
• The conversation captures the address, service need, timing, and access details.
• The job is created.
• The right vendor or crew is selected.
• The customer receives a confirmation.

If any link breaks, a model uptime percentage will not tell you what happened to the job.

Your AI vendor should report operational outcomes, not just model availability. Ask for metrics such as:

• Successful call completion rate
• Percentage of conversations that produce a complete job record
• Tool-call success rate
• Median and 95th-percentile response time
• Failed or abandoned handoffs
• Time to detect degraded behavior
• Time to recover queued work

Those numbers describe whether the system keeps operating when conditions are imperfect.

Failure Detection Must Happen at the Workflow Level

A model can return a technically valid response that is operationally useless. It might misunderstand a street address, omit an emergency detail, or produce a confirmation without actually creating the appointment. A simple health check will miss that failure.

Resilient systems monitor the workflow's expected outputs. For a service call, that might mean checking whether the interaction produced a valid customer record, a service location, a requested time window, and a job status. For dispatch, it might mean confirming that an assignment was accepted by the destination system rather than merely attempting an API request.

Set explicit thresholds. For example:

• If response latency exceeds a defined limit for three consecutive requests, switch to a fallback path.
• If required fields are missing from two consecutive interactions, route the next call to a human.
• If a dispatch action is not acknowledged within 30 seconds, create an alert and preserve the request in a durable queue.
• If error rates rise above a baseline, stop making autonomous commitments until the system recovers.

The exact numbers depend on your operation. The principle does not: detect degraded behavior before a customer or technician becomes the monitoring system.

Context Preservation Is the Real Test

The most damaging outage behavior is not always a dropped request. It is losing the context needed to resume it.

Imagine a property manager calls about a full commercial dumpster. The conversation captures the site address, container size, pickup deadline, gate code, and contact information. The AI service fails while creating the job. If the system only logs an error, someone has to reconstruct the request from memory, a partial transcript, or a recording.

That is not recovery. It is forensic work.

Every AI workflow should maintain a durable job context outside the model session. Store the interaction state as it develops, with clear status transitions such as received, qualifying, awaiting confirmation, dispatched, and completed. If the model becomes unavailable, another process or a human should be able to see what has already been collected and what remains unresolved.

This is also where we extend the argument from Your AI Receptionist Could Be Your Biggest Security Risk. Protecting call data matters, but availability and recoverability matter too. A secure transcript that cannot help your team resume a failed call is still an operational dead end.

Fallbacks Need to Be Real, Tested, and Boring

A fallback plan that exists only in a vendor's sales deck does not count. You need to know exactly what happens when the primary model is slow, unavailable, or returning unreliable results.

Useful fallback layers may include:

• A second model provider for specific low-risk tasks
• A rules-based flow for collecting essential call details
• Direct transfer to an on-call employee
• SMS or voicemail capture when live handling is unavailable
• A dispatch queue that holds work until an operator confirms it
• Manual status boards for urgent jobs

Do not assume that automatic provider switching solves everything. Different providers may share dependencies, have incompatible tool interfaces, or interpret the same business rules differently. A fallback that changes the model but loses the conversation state is not resilient. It is a second failure mode.

Test these paths during business hours and after hours. Simulate a provider timeout. Disable a tool integration. Return malformed data. Force a handoff midway through a call. Then verify that the customer request remains visible, assigned work is not duplicated, and someone knows what action is required.

Recovery Must Prevent Duplicate Commitments

Outages create a dangerous temptation: retry everything. In a dispatch operation, blind retries can create duplicate jobs, multiple vendor assignments, or conflicting customer confirmations.

Use idempotent actions wherever the system can create or update operational records. Each request should have a stable identifier, and a retry should check whether the original action already succeeded before creating a new one. Keep a clear audit trail showing when the request was received, what the AI attempted, what the external system confirmed, and what a human changed.

Define recovery objectives in business terms:

• How long can an inbound call wait before revenue is at risk?
• How long can an urgent job remain unassigned?
• How much context can the team afford to reconstruct manually?
• Which actions require human confirmation after an outage?

These are your practical recovery time and recovery point objectives, even if you never use those technical labels.

The Evaluation Checklist for AI Buyers

Before signing with an AI vendor, ask for concrete answers to these questions:

• What happens when the model times out during a live call?
• Can a human resume the interaction with the full context?
• Where is workflow state stored outside the model session?
• How do you detect partial success, not just HTTP errors?
• Can the system queue work durably during an outage?
• How does it prevent duplicate jobs after retries?
• Which functions have a tested human fallback?
• What metrics and incident history will we receive?
• How often are failover and recovery paths tested?
• What is the expected recovery time for a provider-wide incident?

If the answers are vague, treat that as a product limitation, not a documentation gap.

Reeve is built around the operational layer around AI: capturing job context, connecting calls to dispatch work, and keeping exceptions visible when automation needs help. The model is one component. The workflow is what your business depends on.

The next AI outage is inevitable. Your missed call, lost job, or duplicate dispatch does not have to be. Evaluate resilience as a measurable operating requirement before you put AI on the critical path.