Thanks — this is a clear, practical use case. I’ll address each of your three questions directly, then give a compact, copy‑ready reset snippet and a few operational recommendations to keep your 5 pooled agents healthy over long runs. Acknowledgement: I’m responding to your questions about (1) how to dynamically drop an active SIP call into one of 5 pre-created Rooms, (2) how to fully reset an Agent that stays in a Room between calls, and (3) what to watch for when Rooms/Agents run 10+ hours. 1) SIP dynamic routing (how to drop a live SIP call into a specific pre-existing Room) • Use the API to create or attach the SIP participant directly into the target Room at the moment AMD determines the call is a human. In other words, after AMD signals “human,” call the CreateSIPParticipant (or equivalent SIP participant creation endpoint) and specify the Room name (e.g.,

channel-1

). • This approach inserts the active SIP call into the exact pre-created Room immediately — no need to create a Room or cold-start a worker at that moment. If you want, tell me which LiveKit API client or HTTP call you're using and I can give the exact request payload for your stack. 2) Agent context resetting (how to make a permanently-connected Agent fresh for the next caller) Goal: remove any conversation memory, clear VAD/streaming state, and stop any in-flight TTS so the next caller hears no leftover audio or context. Recommended steps to perform when the caller ends (e.g., on

participant_disconnected

): 1. Interrupt any ongoing generation or playback: ◦ Call the Agent/session interrupt API (e.g.,

session.interrupt()

or session-level interrupt) to stop TTS/audio generation immediately and drop any pending buffers. 1. Clear user/session state: ◦ Clear

userdata

or any session-scoped variables your Agent stores. 1. Reset the chat/conversation context: ◦ Replace the Agent’s

chat_ctx

(conversation history) with a fresh empty ChatContext object. 1. Reset VAD/voice-detection state: ◦ If your VAD has per-session state, invoke its reset method or reinitialize the VAD instance used by that Agent. If using a streaming VAD that resets automatically when a participant leaves, explicitly reinitialize for safety. 1. Clear any tracked participant identity: ◦ Unset the room-level variable that marks which SIP caller is “active” so the room is ready for the next attach. 1. Optionally emit a short ready-state audio or send a small health event to confirm the Agent is ready. Why these steps: interrupting prevents leftover audio from being sent; clearing userdata + chat context ensures the next conversation starts blank; reinitializing VAD avoids stale voice state. 3) Long-running Rooms and Agents (10+ hours): timeouts, token expiration, memory leaks • Tokens: Ensure participant tokens are managed per your authentication model. If you rely on short-lived tokens for security, make sure the pooling Agents use long-lived (or server-managed renewed) credentials. If your Agents are server-side workers with server privileges, they typically maintain their connection without per-call token renewal. • Timeouts: Rooms themselves can be long-lived if you keep at least one participant (the Agent) connected. Make sure server-side connections are robust to network interruptions and include reconnect logic. • Memory/Resource leaks: The SDKs are intended for long-running processes, but you should: ◦ Monitor memory/CPU per Agent process. ◦ Run periodic health checks and restart a worker if memory grows unexpectedly. ◦ Ensure chat history and other caches are explicitly cleared between calls (see reset steps) to prevent unbounded growth. • VAD/TTS streaming: explicitly interrupt/stop in-flight TTS and reinitialize VAD when a call ends to avoid accumulating buffers or streaming state. • Error handling: catch exceptions in the Agent entrypoints and make the agent recoverable without manual restart. Compact Python-style reset snippet • This snippet demonstrates the main actions you should perform when the SIP participant disconnects. Adapt names to your Agent/session objects.

# Example reset logic (pseudo/python-style)
def reset_agent(session, agent_state):
    """
    session: your AgentSession object (STT/LLM/TTS)
    agent_state: structure holding current caller identity, VAD instance, etc.
    """

    # 1) Interrupt any in-progress TTS / generation
    try:
        session.interrupt()  # stops TTS / generation immediately
    except Exception as e:
        # log and continue
        print("interrupt failed:", e)

    # 2) Clear session/user data
    try:
        session.userdata.clear()  # or session.userdata = {}
    except Exception:
        session.userdata = {}

    # 3) Reset conversation/chat context
    try:
        from livekit.agents import ChatContext
        session.chat_ctx = ChatContext()  # fresh empty context
    except Exception:
        session.chat_ctx = None  # fallback

    # 4) Reinitialize or reset VAD
    try:
        if hasattr(agent_state, "vad") and agent_state.vad is not None:
            agent_state.vad.reset()  # if available
        else:
            agent_state.vad = initialize_vad()  # re-create VAD instance
    except Exception as e:
        print("VAD reset failed:", e)

    # 5) Clear tracked caller identity
    agent_state.current_caller_identity = None

    # Agent is now ready to accept the next SIP attach

Event hookup example (conceptual) 1. On `participant_connected`: if a SIP caller is attached and the room is free, mark

current_caller_identity

and begin welcome prompt. 2. On `participant_disconnected`: if identity matches

current_caller_identity

, call

reset_agent(...)

. Operational recommendations and trade-offs • Warm pool (your plan) is the correct pattern to avoid cold-start latency. Keep the 5 Agent workers always connected to their Rooms and idle. • Pre-warm LLM/TT S: keep the model/process alive rather than reinitializing on each call. • If you need absolute zero audio gap, consider a brief pre-recorded greeting buffer that plays instantly on connect while the Agent processes any final per-call setup — but if your reset is fast enough and you interrupt TTS, you may not need this. • Monitor and autoscale: even with 5 pooled agents, monitor how often they’re busy. If required, scale pool size or add a tiny queue to keep user experience smooth. • Safety: ensure only one active SIP participant is allowed per Agent Room, or add a tight guard to reject extra callers. If you’d like, next I can: • Provide the exact CreateSIPParticipant HTTP payload for your language (Python/HTTP) and Room naming conventions. • Convert the reset snippet into the exact function calls for the specific Python Agents SDK methods you’re using (share the package names or a short sample of your Agent session object names). • Suggest a short “instant greeting” audio snippet template you can play during the last 100–300 ms while the agent finishes final reset steps. Would you like the exact CreateSIPParticipant request body and a fully concrete Python example tied to your current SDK names? If so, tell me which client/library version you’re using or paste the relevant session/agent variable names and I’ll adapt the snippet. , with interactive elements