One phone number should never depend on one AI provider

2026-10-20 · Cloudonix Team

This analysis is published by Cloudonix, so weigh vendor claims accordingly.

Your AI receptionist can have a brilliant prompt, a natural voice and a carefully tested transfer flow. None of that helps when its provider cannot accept the call. If that provider also controls the only route behind your published number, a software problem becomes a phone number problem.

The better design keeps the number constant and makes the agent replaceable. That requires two different mechanisms: load balancing to distribute calls deliberately and fault tolerance to respond when a route fails.

The real dependency is behind the number

A phone number is a durable piece of business identity. It sits on your website, in saved contacts and inside customer workflows. Changing it because an AI vendor is impaired is an expensive recovery plan.

Yet single provider deployments often bundle the number, assistant and routing decision into one operational unit. That is convenient during a pilot. It becomes awkward when you need a second provider for redundancy, a regional requirement or a controlled comparison of agent performance.

Cloudonix’s developer documentation calls the alternative voice agent multiplexing. Multiple voice agent platforms can serve the same inbound phone number, enabling fault tolerance and A/B testing. The important change is architectural: the public number terminates in a routing layer you control, while providers become destinations behind it.

Important: Cloudonix explicitly documents multiple voice agent platforms serving one inbound number. OPBX turns that pattern into a configurable DID destination through its AI load balancer.

Load balancing and fault tolerance deserve separate treatment. Load balancing decides which provider should receive a call under normal conditions. Fault tolerance decides what happens when the selected route cannot serve it. You can have either one without the other, although production deployments usually need both.

Put provider selection above the agent

OPBX gives this design concrete pieces. A DID is stored in E.164 format and can point directly to an AI load balancer. That balancer is also available as an extension type, so it can participate in the wider phone system rather than sitting in a separate routing silo.

The AI load balancer supports round robin, priority and percentage strategies. OPBX can route calls to 17 AI voice providers through SIP or WebSocket. It also supports automatic failover and a configurable fallback to an extension, ring group or IVR.

Those strategies solve different problems:

The useful design test is what I call the replaceable agent rule: you should be able to remove one AI provider in staging without changing the number callers dial or the fallback they reach. If that test requires a public number change, provider selection is still too tightly coupled to the agent.

flowchart TD
    Caller["Caller dials one published DID"] --> Cloudonix["Cloudonix session"]
    Cloudonix --> DID["OPBX DID routing"]
    DID --> LB["AI load balancer"]
    LB -->|"selected strategy"| VAPI["VAPI assistant route"]
    LB -->|"selected strategy"| Retell["Retell assistant route"]
    LB -->|"selected strategy"| Other["Another configured AI provider"]
    LB -->|"automatic failover"| Alternate["Alternate configured AI route"]
    LB -->|"configured fallback"| Fallback["Extension, ring group or IVR"]

One DID feeds a routing decision across multiple AI providers, with a separate fallback when AI routing is unavailable.

This also clarifies what still needs engineering. Each provider requires a provisioned assistant, working credentials and an appropriate phone number configuration. Each agent needs equivalent instructions, business data access and transfer behavior. A load balancer cannot make two unrelated agents equivalent.

Start with routes you can actually verify

Before introducing balancing policy, it helps to verify the basic provider connections. This documented CXML routes an inbound Cloudonix call to an existing VAPI assistant through its predefined phone number:

<Response>
    <Dial>
        <Service provider="vapi">+12127773456</Service>
    </Dial>
</Response>

When the call reaches this document, Cloudonix processes <Dial> and routes it to the VAPI service identified by <Service>. The assistant and number must already be provisioned. This snippet performs direct routing; it does not express an OPBX balancing or failover policy.

The equivalent direct route to Retell uses the same CXML structure with a different provider value:

<Response>
    <Dial>
        <Service provider="retell">+12127773456</Service>
    </Dial>
</Response>

That similarity is the point. Provider selection happens at the Cloudonix routing layer, so changing providers does not require reinventing call control. The VAPI and Retell guides also explain how to use your own numbers, including declaring numbers through the provider APIs. For VAPI, Cloudonix recommends its cx-vcc tool for connector setup.

For production redundancy, move above these individual routes. Point the OPBX DID at the AI load balancer, configure the assistant destinations and choose the policy that matches your operational goal. Keep direct CXML routing for simpler applications or controlled tests.

A failure drill on one DID

Consider a support line with a primary AI provider, a secondary provider and a ring group fallback. A caller dials the same published number every time. OPBX selects the primary route. If that route fails, automatic failover tries the alternate. If no AI route is available, the configured fallback gives the caller another path.

sequenceDiagram
    participant Caller
    participant Cloudonix as Cloudonix session
    participant OPBX as OPBX AI load balancer
    participant Primary as Primary AI provider
    participant Secondary as Secondary AI provider
    participant Fallback as Fallback ring group or IVR

    Caller->>Cloudonix: Call the published DID
    Cloudonix->>OPBX: Route the inbound call
    OPBX->>Primary: Attempt selected AI route
    alt Primary route connects
        Primary-->>OPBX: AI session connected
        OPBX-->>Caller: Caller speaks with the agent
    else Primary route fails
        OPBX->>Secondary: Automatic failover
        alt Secondary route connects
            Secondary-->>OPBX: AI session connected
            OPBX-->>Caller: Caller speaks with the agent
        else No AI route is available
            OPBX->>Fallback: Use configured fallback
        end
    end

Failover preserves the caller’s entry point and tries another route, without implying that a live conversation can move between providers.

Make the failure drill boring. In staging, point a test DID at an AI load balancer, configure two assistant routes and start with priority. Exercise the primary route, the alternate route and the final fallback. Use OPBX’s live call dashboard and CDR to confirm that calls reach the outcomes you expected.

Test shared dependencies too. A standby agent that uses the same broken CRM tool has limited value. Provider credentials, telephony connectivity and backend APIs all belong in the test plan.

Warning: Do not describe automatic failover as live call migration. The supplied documentation does not establish that an interrupted conversation can resume on another provider with its audio and context intact.

That distinction matters for customer experience. A caller who reaches a secondary agent may need to start again. Your prompts and fallback messaging should acknowledge that possibility instead of pretending the conversation never broke.

The case for staying with one provider

The strongest counterargument is simplicity. One provider means one assistant behavior, one security review and one place to debug latency or call quality. Cross provider balancing can produce inconsistent voices, different tool behavior and uneven compliance obligations.

Those concerns are real. Cloudonix’s own integration guides instruct customers to review the privacy and security policies of third party AI services. Adding providers expands that work. It also increases the number of test matrices you need before changing a prompt or backend tool.

For a low volume pilot, redundancy may cost more engineering time than the calls justify. A single provider with a clear human fallback can be the responsible choice. The mistake is letting a temporary pilot architecture become permanent without revisiting the dependency.

Self hosting OPBX gives you control over routing configuration, and its MIT license lets you inspect and adapt the phone system. It does not remove every external dependency. Cloudonix connectivity, carriers, AI providers and business APIs still need their own failure analysis.

Adopt priority first, then earn load balancing

My verdict is straightforward. If your number fronts revenue, urgent support or a continuous service, build provider independence before traffic makes the migration painful. Start with priority routing and a fallback. Add distribution only when you have comparable agents and evidence from test calls.

Over the next two quarters, a practical sequence looks like this:

• Move the inbound routing decision behind a DID you control and map every provider dependency.
• Configure a primary and secondary assistant route, then verify automatic failover and the final fallback in staging.
• Compare agent behavior, transfer outcomes and call records before sending production traffic to both providers.
• Introduce percentage routing for a limited canary or A/B test, keeping round robin for agents that genuinely behave alike.

Tip: Start with priority, not traffic splitting. Prove that the secondary route and fallback work before using percentage or round robin distribution in production.

Teams running a small experiment can wait. They should still keep the public number separable from the provider, because that decision is much easier at the beginning.

Where this analysis breaks

I have not assumed vendor outage rates, recovery times or availability improvements. Those figures depend on provider behavior, network conditions and the exact OPBX deployment. The supplied material also leaves health check mechanics and failover timing unspecified, so you need measurements from your own test environment.

The model weakens when agents are functionally different, when both providers depend on the same failing business system or when restoring conversational state matters more than answering the next call. Better observability or more capable agents may change those trade-offs.

To inspect the routing pieces yourself, start with the Cloudonix developer resources and the OPBX repository on GitHub. Build the failure drill before production builds it for you.