Retell AI Multiple Agents on One Phone Number: How It Works

Retell AI multiple agents on one phone number is now handled through weighted agent lists and inbound webhooks, not the old single-agent phone number fields. You can bind more than one inbound, outbound, or SMS agent to a number with weights, or use an inbound webhook to choose the right agent dynamically when a call arrives. The right setup depends on whether you want random distribution, A/B testing, time-based routing, caller-specific routing, or a full call triage workflow.

The important decision is not whether one number can point to more than one agent. It can. The important decision is how the system should choose the agent for each call.

The old single-agent binding model

Older Retell setups commonly treated a phone number as if it belonged to one inbound agent and one outbound agent. That was simple: call the number and the same agent answered every time.

Retell's March 31, 2026 phone-number field deprecation notice moved away from that model. The old single-agent fields were replaced by weighted lists such as inbound agents, outbound agents, inbound SMS agents, and outbound SMS agents. For a single agent, the list contains one entry with weight 1. For multiple agents, weights are split so the total adds up to 1.

That change matters because it makes multi-agent routing a first-class phone-number setting instead of a workaround.

A simple single-agent setup now behaves like this:

• Number: main business line.
• Inbound agents: receptionist agent with weight 1.
• Outbound agents: follow-up agent with weight 1.

A multi-agent setup might behave like this:

• Number: main business line.
• Inbound agents: receptionist agent with weight 0.8, experimental receptionist agent with weight 0.2.

For each inbound call, Retell can pick an agent based on those weights.

Weighted agent lists and current behavior

Retell's update phone number API documentation describes inbound_agents, outbound_agents, inbound_sms_agents, and outbound_sms_agents as weighted lists. If a list is set and non-empty, one agent is picked randomly for each call or SMS with probability proportional to its weight. The total weights must add up to 1.

That is useful for two jobs.

First, A/B testing. You can send 90 percent of calls to the current production agent and 10 percent to a new version. Then compare transcripts, booking rate, transfer rate, and failure rate.

Second, controlled rollout. If a new agent is promising but not fully trusted, give it a small share of real traffic before making it the default.

Weighted routing is not the right tool for caller-specific logic. If you need Spanish callers to go to a Spanish agent, VIP callers to go to a special agent, or after-hours calls to go to a different flow, random weights are too blunt. Use an inbound webhook instead.

Inbound webhook routing

Retell's inbound call and SMS webhook is the more flexible way to use multiple agents under the same number. The docs describe it as a way to dynamically pick the agent, set dynamic variables, reject calls, and pass per-call context for inbound phone and SMS.

A typical inbound webhook routing flow looks like this:

1. Caller dials the Retell number.
2. Retell sends a request to your inbound webhook endpoint.
3. Your endpoint checks caller ID, time of day, campaign, CRM status, or menu choice.
4. Your endpoint returns the agent override and dynamic variables.
5. Retell starts the call with the selected agent.

This opens up much more useful routing patterns:

• Business-hours agent versus after-hours agent.
• English agent versus Spanish agent.
• Sales agent versus support agent.
• New customer agent versus returning customer agent.
• Location-specific agent.
• VIP caller agent.
• Emergency routing.
• Campaign-specific agent.

The inbound webhook is also the right place to inject variables. For example, a returning customer can be routed to the support agent and receive context such as name, open ticket ID, or preferred location.

That variable pattern is covered more deeply in Retell AI Dynamic Variables. The short version: pick the agent and pass the context in the same decision layer when possible.

Choosing between weights and webhooks

Use weighted agent lists when the routing decision does not depend on who is calling.

Good cases:

• A/B testing two prompts.
• Gradually rolling out a new agent.
• Splitting generic traffic across equivalent agents.
• Testing voice or model settings on a small traffic share.

Use an inbound webhook when the routing decision depends on call context.

Good cases:

• Caller phone number lookup.
• Business hours.
• Language preference.
• Location.
• Lead source.
• Existing customer status.
• Service category.
• Urgency.
• CRM ownership.

Do not combine complexity just because you can. A webhook that returns one of two agents based on business hours is understandable. A webhook that also randomizes between five agents, applies location rules, and changes prompts through variables can become hard to debug unless it is logged carefully.

A practical setup for one business number

For a small service business with one public phone number, I would usually start with three agents.

The first is the main receptionist agent. It handles routine inbound calls during business hours, answers common questions, qualifies callers, checks availability, and books appointments.

The second is the after-hours agent. It is more conservative. It answers, takes messages, books only safe appointment types, and avoids making promises that require staff approval.

The third is the escalation or urgent-route agent. It is designed to identify urgent situations quickly, collect minimum details, and transfer to a human or on-call number.

The routing logic can be simple:

• During business hours, send normal callers to the receptionist agent.
• After hours, send callers to the after-hours agent.
• If the inbound webhook or opening triage identifies urgent language, send or transfer to the urgent flow.
• If the caller is a known returning customer, pass CRM context as dynamic variables.

This setup is easier to maintain than one giant prompt trying to behave differently in every situation. It also makes testing cleaner because each agent has a narrower job.

For businesses still deciding how the phone number connects to Retell, Twilio Voice Setup for AI Agents explains the telephony layer, while How to Build an AI Receptionist covers the broader receptionist architecture.

Edge cases to test

Multi-agent routing has a unique failure mode: the wrong agent can answer perfectly. That makes the call sound fine while the business outcome is wrong.

Test these cases:

• Known customer calls from a saved number.
• Unknown caller calls from a new number.
• Caller ID is blocked.
• Call arrives one minute before closing.
• Call arrives one minute after closing.
• CRM lookup is slow.
• CRM lookup fails.
• Caller should route to Spanish agent.
• Caller should route to sales.
• Caller should route to support.
• Weighted rollout sends a call to the test agent.
• Webhook returns no agent override.
• Webhook returns malformed dynamic variables.
• Emergency caller reaches the wrong route.

If the inbound webhook is down, decide what Retell should do. A fallback agent is usually better than dropping the call. The fallback should be conservative and able to take a message or transfer to a human.

Monitoring multiple agents on one number

Once live, measure routing decisions, not just call outcomes.

Track:

• Which agent answered each call.
• Why that agent was selected.
• Whether the call was inbound, outbound, or SMS.
• Whether the caller was known or unknown.
• Which dynamic variables were passed.
• Whether the webhook succeeded.
• Whether the call ended in booking, transfer, callback, or no action.
• Whether the agent selection was later judged correct.

For weighted A/B tests, do not compare only satisfaction or transcript quality. Compare business outcomes: booking rate, transfer rate, call duration, fallback rate, and human correction rate.

For webhook routing, log the routing reason. A record that says "agent_id: abc123" is much less useful than "selected after_hours_agent because local_time was 7:42 PM and caller_status was unknown."

Post-call analysis can help turn those outcomes into fields. Retell AI Post-Call Analysis covers the structured-field side of that reporting.

Common mistakes

The first mistake is using random weights for rule-based routing. If the caller's context should decide the route, use a webhook.

The second mistake is creating too many agents too early. More agents mean more prompts, more test cases, and more ways for behavior to drift. Start with clear jobs.

The third mistake is not logging routing decisions. When a caller complains, you need to know which agent answered and why.

The fourth mistake is ignoring SMS. Retell's current phone-number model includes inbound and outbound SMS agent lists too. If your number handles SMS, make sure routing is deliberate there as well.

The fifth mistake is letting a test agent receive too much traffic too soon. A 10 percent rollout is enough to catch real-call behavior without risking every caller.

Launch checklist

Before using multiple Retell agents on one number, verify:

• Each agent has a narrow job.
• Weighted lists add up to 1.
• The production agent has the expected default share.
• Inbound webhook routes known and unknown callers correctly.
• Dynamic variables are present only when expected.
• Fallback behavior is defined if the webhook fails.
• Business-hours logic uses the caller/business time zone intentionally.
• SMS routing is configured if the number receives texts.
• Test calls cover every route.
• Routing reason is logged with each call.
• Post-call outcomes can be compared by agent.

For production builds where one business number needs sales, support, after-hours, language, and urgent-call routing, Muhammad Bilal's AI Voice Agents service can help design the routing rules and test plan before real callers depend on it.

Frequently Asked Questions

Can one Retell phone number use multiple agents?

Yes. Retell supports weighted agent lists for inbound, outbound, inbound SMS, and outbound SMS routing. You can also use an inbound webhook to choose an agent dynamically for each call.

What are weighted agents in Retell AI?

Weighted agents are agent lists attached to a phone number where each agent receives traffic based on its weight. The weights must add up to 1, and Retell randomly picks an agent according to those probabilities.

When should I use an inbound webhook instead of weighted routing?

Use an inbound webhook when the route depends on context, such as caller ID, time of day, language, CRM status, location, or campaign. Weighted routing is better for A/B tests and gradual rollouts.

Can Retell route after-hours calls to a different agent?

Yes. The inbound webhook can check the time and return a different agent for after-hours calls. Make sure the fallback behavior is clear if the webhook is unavailable.

Can I A/B test Retell agents on the same number?

Yes. Weighted inbound agents are a natural way to send a small share of calls to a test agent while keeping most traffic on the production agent. Compare business outcomes, not just transcript style.

Can one number use different agents for calls and SMS?

Yes. Retell's phone-number model includes separate weighted lists for inbound calls, outbound calls, inbound SMS, and outbound SMS. Configure SMS deliberately if the number receives texts.

What happens if the routing webhook fails?

Your system should have a fallback. The safest option is usually a conservative default agent that can answer, take a message, or transfer to a human rather than dropping the call.

The bottom line

Retell AI multiple agents on one phone number is powerful when the routing logic is simple enough to test. Use weighted lists for rollout and A/B testing, use inbound webhooks for context-aware routing, and log every routing decision. That is how one Retell number can support multiple call experiences without becoming impossible to debug.