If the speech service fails mid-call, Switchboard moves to the next one and carries on talking. The language model is OpenAI or Anthropic, chosen per agent, with a fallback if you want one.
What AI resilience means here
Every critical AI component in Switchboard sits behind a provider abstraction, so no single vendor’s roadmap, pricing page or status page decides what happens next.
Each agent runs on OpenAI or Anthropic, chosen when you set it up, and you can give it the other provider as a fallback. Changing model is a setting, not a rebuild.
Deepgram handles real-time speech recognition today. If it fails mid-call, Switchboard moves to ElevenLabs, then Twilio, and the call carries on. The conversation logic and the case management side don't notice.
ElevenLabs voices speak for the agent today, behind the same provider-agnostic wiring, so we can move when the market does.
Switchboard runs in AWS London, and your case data and audit logs stay in SwiftCase whichever provider is active. It does call outside services for speech and language, so not everything it handles is processed in the UK.
Why it matters
Most AI platforms are built against one LLM vendor, one speech vendor, one voice vendor. That is a convenient story on day one and a hostage situation on day four hundred.
Every major AI provider (OpenAI, Anthropic, Google, and the voice stack vendors) has had public incidents in the last year. Single-provider platforms go dark for the duration. A contact centre or claims line that can't answer the phone is not a small problem.
Prompts tuned for one model version don't always survive the next. When a provider retires a model, single-provider platforms face a forced migration on the provider's timetable, not yours. Multi-provider means you can choose when to move.
Token prices, rate limits, and tier requirements change on provider timelines. A platform locked to one vendor has no leverage. Provider-agnostic architecture turns those changes into a config update, not a business problem.
FCA operational resilience, NHS DSPT, and SRA business continuity expectations all ask how your critical tech fails over. “Our AI supplier went down” is not an answer. Multi-provider failover is something you can write into a BCP and evidence in an audit.
The architecture
Every Switchboard conversation flows through the same stack. Providers sit behind an abstraction layer, not in the conversation code itself.
Calls and texts reach the same agent, with the same SwiftCase tools. Email goes to Switchboard's email agent.
A single interface in front of every AI provider. LLMs, speech-to-text, and voice synthesis are all swappable without rewriting conversation logic.
Each agent has a primary language model, OpenAI or Anthropic, and can be given a fallback from the other provider.
The AI reads and writes SwiftCase cases during the conversation. Tool calls are provider-independent, so a speech failover mid-call doesn't lose the thread.
Case data, workflow engine, audit logs, and customer records, hosted in UK data centres, unaffected by which AI provider is active upstream.
The layers you care about (conversation logic, tool use, case data) live on the SwiftCase side. Providers plug in behind them. Swap a provider and the upper layers don’t notice.
Scenarios
Five real scenarios, with how SwiftCase handles them versus a platform built against a single AI vendor.
Based on how single-vendor AI platforms typically describe failure modes in their own documentation. Always verify specifics with any vendor you are evaluating.
What multi-provider doesn’t protect you from.
Speech recognition fails over today. The language model can be given a fallback, but the agents in production today run on OpenAI alone. Some components (specific voice styles, certain real-time features) have fewer production-ready alternatives. Where that's true, we say so rather than claim a failover that wouldn't help in practice.
If a workflow calls out to your CRM, payment gateway, or carrier API, that system's availability is its own. AI resilience doesn't protect you from a third-party system you chose to integrate with going down.
Failover is a backstop, not a business model. If a provider is consistently below grade, we move the primary, not leave it broken and rely on the fallback.
Questions we get asked
OpenAI or Anthropic for the language model, chosen per agent, with the other available as a fallback. Deepgram for speech-to-text, falling back to ElevenLabs and then Twilio. ElevenLabs for voice synthesis. The list evolves as the market evolves: the point of the architecture is that it can.
We don't quote a figure, because we haven't measured one we'd stand behind. What we can say: when speech recognition fails mid-call, Switchboard moves to the next provider and the call carries on, so the caller doesn't have to ring back. Case data carries over because it lives in SwiftCase, not in the provider.
Yes. Some customers have contractual or compliance reasons to prefer one provider. The language model is chosen per agent, and a fallback is only used if you set one.
No. Multi-provider routing is part of the platform architecture, not a premium tier. You are billed for the usage that happens, regardless of which provider handled it.
The conversation continues. The calling customer does not need to restart. The call stays with Switchboard and the case lives in SwiftCase, so the incoming provider picks up where the last one stopped.
We can provide an architecture summary and the relevant sections of our business continuity documentation under NDA. This is designed to land cleanly in an FCA, NHS DSPT, or SRA review.
We can walk your technical team through the provider abstraction and provide the sections your BCP needs, under NDA.
