# After-hours AI agent with warm transfer while keeping existing number

**URL:** <https://community.livekit.io/t/after-hours-ai-agent-with-warm-transfer-while-keeping-existing-number/1468>\
**Category:** Getting Started\
**Tags:** agent-sdk-node-js, sip-twilio, sip-trunking\
**Created:** [June 20, 2026, 2:58pm UTC](https://community.livekit.io/t/after-hours-ai-agent-with-warm-transfer-while-keeping-existing-number/1468 "2026-06-20T14:58:45Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![royibernthal](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/royibernthal/32/2510_2.png) [@royibernthal](https://community.livekit.io/u/royibernthal)\
**Post date:** [June 20, 2026, 2:58pm UTC](https://community.livekit.io/t/after-hours-ai-agent-with-warm-transfer-while-keeping-existing-number/1468/1 "2026-06-20T14:58:45Z")

</div>

I’m trying to figure out the easiest setup for businesses that want to keep their existing phone number while having an AI voice agent answer after-hours calls and warm transfer to a human when needed. The main goal is to keep the setup as low-friction as possible for the business.

The naive solution I have in mind right now is having 3 phone numbers:

1. Original business number - remains as a client-facing interface - simple call forwarding to a middleware number I manage (2).

2. Middleware number (likely via Twilio) - decides whether to connect with LiveKit agent or forward to a human number (3) based on business hours (probably custom business logic in a webhook).

3. Human number - provide the business with an extra phone number for a human to pick up.

Warm transfer will transfer to the human number (3) as well.

a. Is there a better way to go about it?

b. Will the latency be reasonable? For instance, reaching a human during business hours will go through 2 additional hoops (original → middleware → human)

---

<div class="post-metadata">

**Author:** ![AdvoCube\_Office](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/advocube_office/32/195_2.png) [@AdvoCube\_Office](https://community.livekit.io/u/AdvoCube_Office)\
**Post date:** [June 22, 2026, 7:57am UTC](https://community.livekit.io/t/after-hours-ai-agent-with-warm-transfer-while-keeping-existing-number/1468/2 "2026-06-22T07:57:04Z")

</div>

We built exactly this — here’s a simpler approach than 3 numbers:

Your 3-number architecture adds unnecessary latency and complexity. We run a production warm transfer system (GoFonIA) where the flow is:

Business number → SIP Provider → LiveKit SIP Bridge → AI Agent (single room)  
↓ when transfer needed  
Music Bot (hold)  
↓  
Outbound SIP call to human  
↓  
AI briefs human, human accepts  
↓  
Caller ↔️ Human connected

Key differences from your approach:

1. No middleware number. LiveKit IS the middleware. The business number forwards via SIP trunk directly to LiveKit. One number, one hop.

2. Single room architecture. All participants (caller, AI agent, hold music, human) stay in ONE LiveKit room. We control who hears whom via a 6-phase subscription matrix — no call transfers between rooms.

3. Warm transfer flow:

4. Latency: Business → LiveKit is one SIP hop. The “extra hoop” you’re worried about doesn’t exist because there’s no middleware number — LiveKit handles routing internally.

Tech stack:

- LiveKit Server (self-hosted, Docker)
- Python Agent SDK (livekit-agents)
- Custom transfer controller (aiohttp API on port 9100)
- Music bot (WebRTC participant publishing hold audio)
- PM2 for process management

To answer your questions:

a) Yes, there’s a better way — skip the middleware number entirely. Let LiveKit be the decision point.

b) With your 3-number setup, you’d have ~200-400ms extra latency per hop (SIP signaling + RTP setup). With our approach it’s one SIP inbound + one SIP outbound, both happening in parallel while the caller hears hold music.

The whole thing runs on a single €5/month VPS with 3 PM2 processes. Happy to share architecture details if helpful.

* * *

---

<div class="post-metadata">

**Author:** ![royibernthal](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/royibernthal/32/2510_2.png) [@royibernthal](https://community.livekit.io/u/royibernthal)\
**Post date:** [June 22, 2026, 8:12am UTC](https://community.livekit.io/t/after-hours-ai-agent-with-warm-transfer-while-keeping-existing-number/1468/3 "2026-06-22T08:12:19Z")

</div>

Thanks for the detailed response.

It’d make sense to drop the middleware number if we were only talking about warm transfers, but in your approach, where would the business hours routing logic sit?

---

<div class="post-metadata">

**Author:** ![system](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/system/32/26_2.png) [@system](https://community.livekit.io/u/system)\
**Post date:** [July 7, 2026, 8:13am UTC](https://community.livekit.io/t/after-hours-ai-agent-with-warm-transfer-while-keeping-existing-number/1468/4 "2026-07-07T08:13:14Z")

</div>

Closed on July 7, 2026, 8:13am UTC

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.
