AI Phone Agents: Degraded Mode and the Duty of Care

An AI phone agent is software that answers or places telephone calls and holds a live spoken conversation instead of a person. The question that decides whether it is safe to put on a real line is not how well it converses: it is what happens to a caller when the AI phone agent cannot answer, cannot understand, or must not be the one answering.

Our position is that a phone line is different from every other AI surface a company deploys, because it is the channel people fall back to when the others have failed them. That makes availability a duty rather than a metric, and it makes the failure path — not the happy path — the part of the system that has to be designed first. A practitioner building this for clients put the dependency problem plainly on Hacker News during a model-provider incident in March 2026: the hardest conversation with a customer, he wrote, is explaining that "your system's uptime is fundamentally capped by your LLM provider's uptime" (evara-ai, Hacker News, 3 March 2026).

The short answer: An AI phone agent inherits the combined downtime of every service in its call path and adds new ways to fail a caller who is in an emergency, in distress, or hard for a recogniser to hear — so build the ladder of things that answer when it cannot, and make sure no rung on that ladder depends on the rung above it.

Last updated: July 31, 2026.

The Answer Ladder: five rungs a call can fall to, and the rule that each must survive the failure of the one above.

We have not operated a production AI phone agent ourselves, and nothing here is offered as our operating experience. What we did do is read the Federal Communications Commission rule text at source rather than in summary, pull the availability commitment out of a major telephony vendor's own published service level agreement, and work the composite-availability and queue-capacity arithmetic ourselves from those published figures. That arithmetic is shown in full below so you can check it. Where a source a reader would expect was unreachable, the article says so. Nothing here is legal advice; the emergency-calling and accessibility rules cited are sector-specific and under active amendment, and how any of them apply to a particular deployment is a question for counsel.

What an AI phone agent is, and what this article covers that the others do not

An AI phone agent is a system that holds a live telephone conversation on behalf of an organisation: it converts the caller's speech to text, decides what to say and what to do, takes actions in your systems, and speaks a reply back in a synthetic voice. That definition is uncontroversial, and on its own it is not worth 6,000 words.

Two adjacent problems in this channel are already covered, and this article deliberately does not re-argue them.

The third question is the operational one, and it is the one that lives after the demo. A demo shows the agent working. It cannot show you the Tuesday afternoon when a speech recognition vendor has a regional incident and everyone who was told to "just call us" hears a ring tone that goes nowhere.

There is a specific tension between the first article and this one that is worth naming immediately, because it is the sharpest architectural trade-off in the category. The single largest latency reduction available to a voice pipeline is colocating telephony, speech recognition, the model and speech synthesis in one region. Every one of those hops costs milliseconds, and callers notice milliseconds. But a single region is also a single blast radius. The design that makes the agent feel human is the same design that makes all four stages fail together. You cannot optimise both without paying for it somewhere, and it is a trade-off that is easy to make implicitly and expensive to discover later.

Why the phone is the channel of last resort

The phone is the channel people use when the other channels have already failed them, when the matter is urgent, or when they cannot use the others at all. That is not a sentimental claim about human contact. It is a structural property of the channel, and it changes what an outage means.

Consider what a failure costs in each channel a company runs.

The last row is the one that matters. A failed email leaves an artefact the sender can point at. A blocked or dropped call leaves nothing at all: no queue position, no ticket number, no record on either side that the person tried. The caller's only remedy is to call again, which is also the behaviour that makes an incident look like a traffic spike.

Three groups have reason to reach for the phone first rather than last, and they are disproportionately the people an outage hurts. People whose matter is time-critical, because a form has no deadline and a phone call feels like it does. People who have already tried the other channels and been failed by them, who arrive frustrated and with a longer story. And people for whom voice is the accessible channel rather than the convenient one — which is a group this article returns to at length below.

Regulators treat voice this way too, which is a useful sanity check on the intuition. Under the Commission's E911 rules, an interconnected VoIP provider must "specifically advise every subscriber, both new and existing, prominently and in plain language, of the circumstances under which E911 service may not be available", and the rule names the circumstances it has in mind, including "broadband connection failure, loss of electrical power" (47 CFR 9.11(b)(5)). Note the shape of that obligation: not "make it reliable", which no one can promise, but "tell people, in advance, when it will not work." That is a duty about the failure state, written into the rules of the channel, and it is a good model for how to think about an AI phone agent even where the rule itself does not reach your support line.

The dependency chain: everything that has to be up for one call to work

A single AI-handled call depends on a chain of services that must all be working simultaneously, and the chain is longer than the one a chat widget depends on. Availability multiplies down a serial chain, so the composite number is always worse than the worst individual component, and worse than the figure on any single vendor's page.

Here is the chain for a conversational inbound call that can also take an action in a system of record.

Six links. Consider what happens if every one of them held to the standard commitment on a well-known telephony vendor's published terms: Twilio's APIs service level agreement, last updated 9 April 2026, commits to a monthly availability of 99.95% for standard services and 99.99% for its Enterprise and Administration editions, calculated as (A-B)/A * 100 over total monthly API time.

We ran that arithmetic rather than asserting a rule of thumb. Six independent components at 99.95% each give a composite of 0.9995^6 = 0.99700, or 99.70%. Over a 30-day month that is about 129 minutes — a little over two hours — in which at least one link in the chain is down. At the 99.99% enterprise tier, six links give 99.94%, or about 26 minutes.

Three caveats belong with that table, and dropping any of them would make it dishonest. It is an illustrative model built from one vendor's published commitment, not a measurement of anyone's actual voice stack. Real dependencies are not independent — several of these components frequently sit in the same cloud region, which makes correlated failure more likely than the multiplication implies, not less. And a service level agreement is a commercial commitment about credits, not a prediction: Twilio's own remedy for a breach is a service credit of "10%" of the affected fees for that month, applied to future billing. Ten percent of a month's telephony spend is not the price of two hours of unanswered calls, and it is not offered as one. The number to plan against is your own measured availability, and until you have measured it, the multiplication is the better prior than the individual figure on the vendor's page.

Correlated failure is not hypothetical. Amazon Web Services' own post-event summary of the 19-20 October 2025 disruption in the N. Virginia region records that the event ran from 11:48 PM PDT on 19 October to 2:20 PM PDT on 20 October and describes three distinct periods of impact across DynamoDB, Network Load Balancer and EC2 instance launches, triggered by "a latent defect within the service's automated DNS management system" (AWS post-event summary). Any voice stack that had followed the latency advice and colocated all of its components in that region had one incident, not six.

Availability multiplies down a serial chain. Six links at 99.95% each is 99.70% together.

The Answer Ladder: five rungs and one rule

Every inbound call should have a defined thing that answers it at each level of system health, and each of those things must survive the failure of the one above it. Call this the Answer Ladder, and its governing constraint the Last Rung Rule: no rung may depend on the rung above it.

Rung 5 is the one to build first, because it is the one you will need under the worst conditions and the one that is hardest to produce while an incident is running. A recorded message that says the line is affected, states an alternative, and gives an estimated return is an unhurried two-minute job in peacetime and an emergency task once an incident is running.

The Last Rung Rule sounds obvious and is easy to break, because a fallback is naturally written as a branch inside the thing that fails. Three concrete versions of the violation:

• The "transfer me to a human" intent is detected by the model. When the model provider is down, the escape hatch is down. Keyword and DTMF escapes have to be handled by the telephony layer, which is one link earlier in the chain.
• The outage announcement is served by the same application that serves the conversation. If the application is the failure, no one hears the announcement.
• The callback promise writes to the CRM. If the CRM outage is what degraded the agent in the first place, the promise is made and lost, which is worse than not making it.

There is a fourth violation that is organisational rather than technical: voicemail is switched off during the AI rollout because the AI phone agent is meant to replace it. Voicemail is the rung that requires the fewest working components. Removing it is removing the cheapest floor you have, in exchange for a metric.

One honest counterargument. Voicemail has a genuinely poor reputation, and it deserves part of it: unattended mailboxes and unanswered messages are a real failure of their own, and a caller who leaves a message that nobody returns has been failed twice. That is an argument for owning the mailbox — a named owner, a response clock, a monitored queue — rather than for deleting the rung. A rung nobody watches is not a rung. The fix is staffing and ownership, not removal.

The capacity trap: deflection is a load-bearing assumption

An AI phone agent that handles a share of your call volume changes the size of the human team you keep. That is the point of it. It also means that when the agent fails, the human queue receives the volume it was sized to no longer receive, and the arithmetic is unforgiving.

Work it through with round numbers. A line takes 1,000 calls a day across a 12-hour day, so a two-hour window carries about 167 of them. Before deployment, humans handle all 167. The AI phone agent then resolves 60%, so humans handle 67 in that window, and the team is resized accordingly. Now the agent is unavailable for those two hours. All 167 calls arrive at a human queue staffed for 67. The queue is receiving 2.5 times the load it is built for, at the worst possible time, and the callers arriving are not a random sample — they include everyone the agent would have resolved silently, plus everyone redialling because their first attempt went nowhere.

(Assumes 1,000 calls spread evenly across a 12-hour day, which is about 83 calls an hour and 167 in a two-hour window; 40% of 167 is 67, and 217 divided by 67 is 3.2.)

The redial row is the one easiest to leave out of capacity planning, and it is the row that turns a two-hour vendor incident into a four-hour customer-service incident. It is also self-reinforcing: longer queues produce more abandonment, abandonment produces more redials, and the redials arrive as new calls with no memory of the first attempt.

Three planning consequences follow, and none of them require new technology.

Decide the surge posture before you need it. Someone has to be able to say, during an incident, whether the answer is overflow staffing, a callback queue, a recorded message, or a deliberate decision to let hold times rise. That decision is much worse when made at speed by whoever happens to be in the room.

Size the human floor against degraded load, not steady-state load. The honest question is not "how many agents do we need now that AI handles 60%", it is "how many agents do we need to not fail catastrophically for the two hours a month when it handles 0%". Those are different numbers, and the gap between them is the real cost of the deployment.

Keep the humans current. A team that only ever sees the 40% the agent could not handle loses fluency in the routine 60%. When the agent falls over, they are handling call types they have not touched in months, at 2.5 times normal volume. Deliberate rotation through ordinary calls is cheap insurance, and it is also the easiest thing to quietly stop doing.

The queue was resized for the deflected volume. During an outage it receives all of it, plus redials.

What a degraded AI phone agent should sound like

A degraded AI phone agent should say what it cannot do, offer the next rung down, and stop pretending. The wording is not a copywriting exercise; it is the interface to the failure, and it is the only part of the incident the caller ever sees.

The practitioner quoted at the top of this article named the pattern from production experience: for real-time systems, have a scripted fallback path, because a line like "I'm having trouble processing that right now — let me transfer you to a human" is, in his words, "infinitely better than a hung connection or error message" (evara-ai, Hacker News, 3 March 2026).

That principle generalises into a small set of rules for what the agent says when things are wrong.

Two specifics are worth stating plainly, because both are easy to get wrong in ways the caller feels at once.

Set a hard deadline on every turn, not just a timeout on the request. If the agent has not begun speaking within a fixed budget, it should stop waiting and take the next rung. Timeouts on the underlying API call are not the same thing: an API can return successfully after eleven seconds, and eleven seconds of silence on a phone call has already lost the caller.

Cap repair attempts. A conversation that has failed to understand the caller twice is unlikely to succeed on the fourth attempt, and each additional attempt is a specific insult to a caller whose speech the recogniser is not built for. Two attempts, then offer an alternative, is a defensible default. Unlike a latency budget, this one is a design choice you can simply make.

The four callers you cannot average

An average is a comfortable instrument for signing off a deployment and the wrong one here, because the callers most likely to be failed by an AI phone agent are the ones least represented in the average. Four groups need a designed path rather than a statistical one. Call them the four callers you cannot average.

The caller with an emergency. Not every business line is an emergency line, but some are adjacent to one: a gas utility, a care provider, a property manager, an insurer taking a first notice of loss, a health service. A caller in a genuine emergency does not follow the menu, does not answer qualifying questions, and cannot be put in a callback queue. The design requirement is an unconditional, early, keyword-and-keypad escape that is handled at the telephony layer rather than by the model, plus a spoken instruction near the start of the call telling anyone in immediate danger to hang up and dial the local emergency number. That instruction costs about three seconds and is the single highest-value sentence in the script.

The caller in distress. Bereavement, financial hardship, safeguarding, a customer who has just received bad news. The failure here is not a technical one. The agent works perfectly and behaves inappropriately. Detection is genuinely hard and we would not build the whole control on it. The controls that do not depend on detection are structural: distress-adjacent call types (bereavement lines, hardship lines, complaints of a defined class) should route to humans by configuration, before any classification happens, and any distress signal that is detected should trigger an immediate transfer rather than a change of tone.

The caller the recogniser cannot hear. This is the failure mode with the best published evidence behind it. In a study of five commercial speech recognition systems, researchers found "an average word error rate (WER) of 0.35 for black speakers compared with 0.19 for white speakers", across 19.8 hours of matched audio from 42 white and 73 black speakers, and traced the gap to the underlying acoustic models rather than to vocabulary (Koenecke et al., PNAS, 2020). That study is from 2020 and the systems have moved since, so we do not present it as today's number. We present it as the reason to measure your own. The direction of travel is visible in the University of Illinois Urbana-Champaign's Speech Accessibility Project, which as of the end of September 2025 had collected recordings from about 2,000 participants with diverse speech patterns and disabilities, and reports that "Microsoft announced 18% to 60% accuracy gains using our data" (Speech Accessibility Project). A gap that a vendor closes by 18% to 60% with better data was a real gap.

The operational consequence is uncomfortable and simple. A single aggregate recognition accuracy figure hides exactly the population you are about to fail, and the breakdown is not something a datasheet carries. The measurable proxy you can build yourself is the escape rate: how often calls end in a fallback, sliced by anything you legitimately hold, and above all by repeat callers. A caller who is transferred out on every attempt is telling you something the average is not.

The caller who cannot use voice at all. Deaf, hard-of-hearing, deafblind and speech-disabled callers reach voice lines through relay services, and the mechanics of that are settled rather than speculative. Common carriers providing telephone voice transmission services must provide telecommunications relay services and "shall provide access via the 711 dialing code to all relay services as a toll free call", and speech-to-speech relay service must also be provided (47 CFR 64.603). A relay call reaches your line through a human or automated intermediary. It has different timing, different turn-taking and often typed input rendered as speech — which is to say, it looks nothing like the traffic your agent was tuned on. Europe is pushing the same requirement from the other end: the European Accessibility Act's recitals state that for electronic communications services including emergency communications to be accessible, providers should "in addition to voice, provide real time text, and total conversation services where video is provided by them" (Directive (EU) 2019/882, recital 28). Whether that Directive reaches an ordinary company's customer-support line, as opposed to an electronic communications service, is a scope question we are not going to resolve for you; it is a question for counsel. The design point stands regardless of the answer: if your only accessible route into the company is a phone line, and that phone line is an AI phone agent tuned on fluent conversational speech, you have made the accessible route the least reliable one.

Four caller types, four different failures, and the control for each that does not rely on the model getting it right.

What the rules already settle, and what they do not

Some of this is settled law and some of it is genuinely open, and the useful thing is to know which is which. What follows is context, not advice, and the distinction matters more than usual here because the rules below were written for telephone systems generally rather than for AI phone agents specifically.

Two rules are settled and quotable.

The first is Kari's Law, implemented at 47 CFR 9.16. A person in the business of installing, managing or operating a multi-line telephone system may not do so "unless such system is configured such that a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9". The same section requires that where MLTS notification is configured, it "must not delay the call to 911" and "must be sent to a location where someone is likely to see or hear it".

Read that as an engineering principle rather than as a compliance item and it is exactly the Last Rung Rule, written into United States law for a different generation of phone technology: the emergency path must not be mediated by, gated on, or slowed down by the clever system in front of it. Whether an AI phone agent sitting on a business phone system falls inside the definition of a multi-line telephone system for the purposes of that rule is not a question we are going to answer, and we have found no published enforcement action applying it to a conversational voice agent. Treat it as an open question and put it to counsel. The design conclusion does not depend on resolving it.

The second is the disclosure duty already quoted above: 47 CFR 9.11(b)(5) requires interconnected VoIP providers to tell subscribers, in plain language and in advance, the circumstances in which emergency service may not be available, and to keep a record of each subscriber's acknowledgement. Again the transferable principle is about the failure state: the obligation is to be honest about it beforehand rather than to promise it away.

Three things are not settled, and pretending otherwise would be the easiest way to mislead a reader.

The reason to be this careful is not timidity. It is that an article which resolves a contested legal question for you is an article you might act on, and the honest position on all three of these is that the design answer is the same whichever way the legal answer goes.

A worked outage: forty-one minutes, annotated

Here is one complete incident with its timeline, written as it would look from inside the company. The scenario is composed to make the failure modes above concrete; it is not a report of an event we witnessed. A retailer's inbound support line runs an AI phone agent that resolves roughly 60% of calls. Its speech recognition vendor has a regional incident during afternoon peak. The vendor incident itself runs forty-one minutes, from 14:02 to recovery at 14:43; the last row shows what it left behind afterwards.

The two most expensive rows are 14:18 and 14:50, and neither is a technical failure. One is an asset nobody made in advance; the other is a rung nobody kept. The interval from 14:15 to 14:26, eleven minutes to change what the phone line says, is the number we would put on a dashboard and rehearse down, because it is the one thing entirely within your control during someone else's outage.

Testing the failure path: the drill worth one afternoon

You test an AI phone agent's failure path by deliberately breaking each dependency in a controlled window and calling the line yourself. Everything else is inference. It is one of the cheapest high-value exercises in the whole deployment, and it is easy to defer because it feels like it belongs to a maturity the team has not reached yet.

A drill worth running takes an afternoon.

1. Pick one dependency and disable it in a controlled way. Block the speech recognition endpoint, revoke the model API key, take the CRM integration offline. One at a time, in a maintenance window, with the line either off-hours or diverted.
2. Call the line yourself, as a caller, from a mobile phone. Not a test harness. The harness will tell you the API returned an error; only the phone will tell you that the caller hears eleven seconds of silence first.
3. Time the interval from failure to an honest message. From the moment the dependency dies to the moment a caller hears something true. That interval, not the vendor's recovery time, is your number.
4. Verify each rung independently. Confirm rung 3 works when rung 2's dependency is down, and rung 4 when rung 3's is. If a rung only works when the rung above it works, it is not a rung.
5. Run it once with the person who normally fixes it on holiday. The runbook that only works when its author is available is a personal capability, not an organisational one.
6. Do the relay leg. Place a call through a relay service, or at minimum through a text-to-speech intermediary, and listen to what your agent does with the timing. It is a leg that is easy to leave out of a test plan entirely.

If one or two of those six fail the first time, the drill is working rather than failing. That is the reason to run it before an incident chooses the timing for you.

What to instrument, and what a status page will not tell you

Instrument caller outcomes, not dependency health, because a dependency can be green while your callers are being failed. A vendor status page reports the vendor's view of its own service, aggregated across its whole customer base, and updated by humans after they have agreed there is an incident. It is a lagging, coarse, second-hand signal about someone else's system.

The last row is the one to automate. A synthetic call placed on a schedule that walks the ladder, from full agent down through no-tools, human route, capture and recorded message, is a small piece of engineering that catches the thing the drill catches, continuously. It is the phone equivalent of a health check that actually exercises the code path rather than pinging a port.

One caution about alerting on escape rate: it moves for legitimate reasons too, such as a new campaign driving unfamiliar intents. Alert on the rate of change against the same hour of the previous week rather than on an absolute threshold, and expect to tune it. An alert nobody trusts is worse than no alert, because it trains the team to wait for the second signal.

Nine questions to ask a voice vendor about failure

Vendor evaluation for an AI phone agent runs on accuracy, latency, integrations and price. These nine are about the state the demo never enters, and each has an answer you can check rather than a claim you have to accept.

Question 8 is the one we would ask first, because almost nothing else in the list is as diagnostic of whether the vendor has thought about callers rather than about calls.

What an AI phone agent is not

Four clarifications that save arguments during an incident review.

It is not a highly available system by default. It is an application composed from several third-party real-time services, and its availability is the product of theirs unless you have deliberately built otherwise. Nothing about the category makes it resilient; several things about it make it less so than the IVR it replaced.

It is not a replacement for the fallback rungs beneath it. It sits on top of them. Removing voicemail, the human queue or the recorded-message capability because the agent handles those cases is removing the floor because the ceiling is nice.

It is not a safety system. A line adjacent to emergencies needs an unconditional path out, and that path should not be a feature of the agent. It should be a feature of the phone system the agent runs on.

It is not measured by its average. Aggregate containment and aggregate accuracy hide the callers who are failed every time. The escape rate for repeat callers is a more useful number than the containment rate for all callers, and it is a different number from the one a containment dashboard reports.

When the line should not have an AI phone agent on it at all

Sometimes the correct recommendation is not to deploy, and saying which cases those are is more useful than a caveat.

The fourth row is the one that gets argued with and it is the most defensible. Every control in this article requires a person who is accountable for the line's behaviour during an incident. Without that, you have not deployed an AI phone agent, you have deployed an unattended system on your most exposed channel.

Where LeapForce fits, and where it does not

LeapForce does not sell an AI phone agent, telephony, a speech stack or a contact-centre platform, and nothing in this article describes our product. What we build is the layer underneath: one controlled layer for every AI tool, connector, model and agent, so that access, policy, cost and audit are answered once rather than per vendor.

The connection to this topic is narrow and real. A phone agent's failure path is mostly a question about identity, scope and evidence: which agent may take which action, what it is allowed to promise when a downstream system is unavailable, who owns it, and what record exists of what it refused. We treat non-human identities as first-class, with an owner, a scope and an expiry per agent, which is the same discipline the fourth rung of the Answer Ladder needs when a callback promise has to be honoured by somebody. Our observability and audit approach records what an agent was refused as well as what it did, and a refusal log is what an incident review actually needs. Human approval gates are the same control described in our earlier piece on human-in-the-loop automation. Our rollout model is deliberately unexciting — Observe first. Enforce second. Optimize third. — because you cannot write a sensible degradation policy for AI surfaces you have not yet found. LeapForce is in active development and per-capability build status is disclosed on those pages; take them at their labels.

Honest limits and open questions

Where this analysis is uncertain, and where we would want more evidence before betting on it.

• The availability arithmetic is a model, not a measurement. We derived it from one vendor's published commitment and stated the multiplication in full so it can be checked. It assumes independence between components, which is optimistic, and it uses a contractual commitment rather than observed uptime, which is a different thing. Your own measured figure beats it.
• We could not find published availability data for AI voice platforms. We looked for measured, methodologically transparent uptime figures across commercial voice AI platforms and found none that were not vendor-published. That absence is itself the finding, and it is why the model above is built from a telephony SLA rather than from a voice-agent benchmark.
• The recognition disparity evidence is five years old. The Koenecke study measured five systems in 2020, and speech recognition has changed a great deal since. We cite it because it is the best-documented measurement of the gap we could reach, not because it describes today's error rates. The correct response is to measure your own escape rates by caller, not to assume either that the gap persists at that magnitude or that it has closed.
• The worked outage is composed. It is built from the failure modes documented above rather than from an incident we observed or were told about. We have flagged it as composed in the section itself for the same reason.
• We have run no production AI phone agent. No containment rates, no answer rates, no recovery times of our own appear anywhere in this article.
• Two sources a reader would reasonably expect were unreachable. Ofcom's guidance on protecting access to emergency organisations during a power cut, the closest published analogue to a duty-of-care rule for degraded voice service, returned 403 to every fetch method we tried, so we make no claim about its contents. The FCC's own consumer guide to telecommunications relay services also returned 403, so the relay position here is cited from the Code of Federal Regulations text instead, which is the primary source anyway.
• No video accompanies this article. The YouTube Data API's daily search quota was exhausted on the day of writing, so we could not run a real search and we would rather ship none than guess at one.
• The legal questions are flagged, not answered. Three questions in the rules section are genuinely open on the sources we could reach, and we have deliberately left them open rather than resolving them for a reader who might act on the resolution.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.