“If an agent disconnects unexpectedly, LiveKit detects it within ~15 seconds and dispatches a new agent.” But there’s no documentation on what happens when workers reject -- it’s unclear if LiveKit tries every single worker or gives up.

Thanks for reaching out, luisa. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

can you give a concrete example by what do you mean with agents to give distinct name? we already give agents distinct name agent-AJ_pFW8byHphyRG

Thanks — I’m responding to your request for a concrete example of named agents and explicit dispatch (you mentioned an agent named

agent-AJ_pFW8byHphyRG

). Below is a concise example flow showing how to name agents and explicitly dispatch to them. 1) When you create/register the agent process, set its name (example in pseudocode):

agent = Agent.create(name="agent-AJ_pFW8byHphyRG")
agent.connect()

2) Create a room and specify which named agents may be dispatched:

{
  "room": "support-call-123",
  "agents": [
    "agent-AJ_pFW8byHphyRG"
  ]
}

3) Or create an explicit dispatch to add an agent to an existing room:

dispatch = CreateDispatch(room="support-call-123", agents=["agent-AJ_pFW8byHphyRG"])

Notes: • Named agents do not receive automatic dispatch from the default pool. Only rooms or dispatch rules that list that name will route jobs to that agent. • If multiple instances share the same name (for blue/green or scale), LiveKit will load-balance between them. • If you want fallback routing, list multiple agent names in the

agents

array in order of preference. If you’d like, tell me: • how you currently register agents (SDK/language), and • whether you want automatic fallback to other agents — I can give exact code snippets for your stack., with interactive elements

so to give a concrete example if a have a campaign that has an agent attached to it agent in the set of a gym sales guy, if we give it the same name as in the agent id of our app how would it perform load balance?

We know named agents disabled auto dispatch; multiple agents same name load balance. Built-in system performs round-robin with single-assignment. Provide concrete example: campaign with agents named by app agent ID; multiple instances with same name load balance. Mention listing multiple names for fallback. Ask if they want language-specific snippets. Keep warm tone.You're asking how load balancing works when multiple agent instances share the same name (for example using your app's agent ID as the agent name) for a campaign. Here’s a concise, concrete explanation and example. What happens • If multiple agent processes register with the same name (e.g.,

agent-12345

), LiveKit will load-balance incoming jobs among those instances. • The server uses a round-robin / single-assignment approach: each job is assigned to one agent instance; if that instance doesn't accept within the timeout, the job is sent to another available instance. • Named agents disable automatic dispatch from the default pool; only rooms/dispatch rules that explicitly list that name will route jobs to them. Concrete example • You have a campaign for gym sales and want any available gym-sales rep instance to handle calls for that campaign. • Register each worker process with the same name (the app agent ID): ◦ instance A: name =

agent-gym-42

◦ instance B: name =

agent-gym-42

◦ instance C: name =

agent-gym-42

• When you create the room/dispatch for the campaign:

{
  "room": "gym-campaign-001",
  "agents": [
    "agent-gym-42"
  ]
}

• Jobs for

gym-campaign-001

will be distributed across A, B, and C by LiveKit’s load balancer. Fallbacks and preferences • If you want a strict fallback order (try agent X, then Y), list multiple agent names in the

agents

array in order of preference. • If you want any available rep from several groups, you can include multiple names (or use the same name across all instances) to enable load-balanced distribution. Would you like an example in your SDK/language or guidance on fallback ordering vs. single shared-name load balancing? , with interactive elements

Does this only work for cloud based Livekit?

Short answer: Named agents and the load‑balancing behavior work on any LiveKit deployment (cloud or self‑hosted) as long as the LiveKit server supports Agents (v1.3+). Details: • This behavior is implemented in the LiveKit server itself, not specific to the cloud offering. • If multiple agent processes register with the same name (e.g., your app agent ID), the server will load‑balance jobs across those instances (round‑robin/single‑assignment). If an assigned instance times out or fails to accept, the job is retried on another instance. • Named agents disable automatic dispatch from the default pool—rooms or dispatch rules must explicitly list the agent name(s). • The same config and patterns (shared name for load balancing, multiple names for ordered fallback, explicit dispatch via

agents

on room/create dispatch) apply equally to cloud and self‑hosted deployments. Would you like a quick checklist to verify your self‑hosted server version and agent registration settings? , with interactive elements

so if I wanted to work, I should not name the agents

Good question — here’s a concise recommendation. • Naming an agent disables automatic dispatch for that agent. If you give agents the same name, LiveKit will load‑balance only among instances that registered with that name and only for rooms/dispatches that explicitly list that name. • If you want LiveKit’s automatic/default dispatch pool (jobs routed to any available agent without explicit names), do not name your agents (leave name blank). That lets the server route jobs automatically across the default pool. • If you need control (route certain campaigns to a specific group or do blue/green deployments), use names deliberately: ◦ Same name on multiple instances = load‑balanced pool for that named group. ◦ Multiple names in a room’s

agents

list = ordered fallback / explicit dispatch. Which behavior do you want for your campaign — fully automatic routing, a dedicated named group, or ordered fallbacks? I can give exact config/code for your stack. , with interactive elements

wait does it dispatch in round robin? not in least load?

Short answer: LiveKit uses round‑robin / single‑assignment dispatch — not least‑load. How it behaves: • Jobs are assigned in a round‑robin fashion across eligible agent instances (or across instances that share the same agent name). • Single‑assignment means each job is sent to one instance; if that instance doesn't accept within the timeout, the job is retried on another instance. • There is no built‑in least‑loaded scheduling that measures current CPU/connection counts to pick the lightest instance. If you need least‑load behavior, you can: • Implement a custom dispatcher that queries agent health/metrics and explicitly lists preferred agent names in the

agents

array, or • Have agents report load to a central coordinator and let that coordinator call

CreateDispatch

with the chosen agent name. Would you like an example of a custom dispatcher for your language/stack? , with interactive elements