Thanks — good question. I’m responding about the agent handoff behavior in a self-hosted setup. Short answer • During an agent handoff, a new agent server is not instantiated. The handoff runs on the same agent server. How it works (concise) • An “agent server” is a long-running process that registers with the LiveKit server and manages many jobs (agent sessions). • Each job runs in its own isolated process. When a handoff happens, control is transferred to a different agent implementation inside that existing job process. • The session keeps the same underlying resources and room connection; the new agent begins executing within the same session context (unless you explicitly reset session state). Why this matters for self-hosting • You don’t need to spawn additional server instances per handoff. • Resource usage stays tied to your existing agent server and its job processes; plan capacity for concurrent jobs rather than for handoffs themselves. If you want, I can: • Explain which parts of the session state persist across a handoff and which you might need to explicitly transfer. • Walk through an example flow of how a handoff is triggered and how the new agent is invoked in your job process. • Help you check your current deployment to confirm how jobs and agent processes are configured. Which of those would be most helpful? Sources: Agents and handoffs | LiveKit Documentation