Thanks — this is a great question. You’re asking how to ensure your self‑hosted LiveKit agents (deployed across regions) are the ones dispatched to a room such that the agents closest to the LiveKit Cloud SFU handle the user. I’ll be direct and practical. Short answer • LiveKit does not automatically perform geographic/proximity-aware dispatch for self‑hosted agents. Geographic affinity (automatic matching of users and agent servers by location) is only provided when using LiveKit Cloud’s managed agents. • For self‑hosted agents you need to implement region-aware routing yourself. Below are practical approaches you can use depending on your architecture. Why: current behavior • Self‑hosted agent dispatch uses a readiness/load based system and does not consider geographic proximity when assigning jobs. • If an agent fails to accept a job within the dispatch timeout, the job is retried to another available agent (no built‑in region preference). Workarounds / recommended options Choose the approach that best fits your infrastructure and control requirements. 1) Region-tagged agents + token-based explicit dispatch • Deploy agents with region-specific identifiers (for example:

agent-us-east

,

agent-eu-west

). • When issuing a room join token, include a room/agent configuration that specifies which agent(s) to target for that room. • Determine the best region for a user before creating the token (client geolocation, IP-based geolocation, or a client-side latency probe) and issue the token that dispatches to agents in that region. Benefits: deterministic routing, simple to operate. Tradeoffs: you must implement the region selection logic when issuing tokens. 2) Regional dispatch proxy (recommended for larger fleets) • Deploy a small orchestration service in each region. • When a user wants to join, the client calls the regional orchestrator (or you route them to the regional orchestrator), which: ◦ Picks the nearest agent instance in that region (or checks local agent pool health/available capacity). ◦ Calls the AgentDispatch API (or creates the dispatch via your server SDK) with the chosen

agent_name

. • Optionally combine with health checks and a small local queue to handle short bursts or agent churn. Benefits: centralized control per region, real-time health/availability checks, easier autoscaling per region. Tradeoffs: more infrastructure to operate. 3) Network/DNS-based routing + regional agent pools • Use latency-based DNS/CDN routing (e.g., Route 53 latency routing) or any traffic steering so clients connect to the closest ingress/region. • Maintain an agent pool co‑located with those ingress endpoints. • Use simpler dispatch rules that bias toward the local pool (via agent naming or regional orchestrator). Benefits: leverages existing network routing; fewer application changes. Tradeoffs: less precise than direct latency measurement; depends on DNS routing behavior. Implementation notes and practical tips • Tag your agent instances clearly with region metadata so orchestrators or token builders can pick them. • If you use token-based routing, generate tokens only after determining the best region for the user. • If you need to measure latency client-side, short UDP/TCP probes or WebRTC ICE connectivity checks can help pick the nearest region dynamically. • Add health checks and capacity metrics to avoid routing to overloaded local agents. • Consider fallback logic: if the preferred region’s agents don’t accept a job, retry to other regions (this mimics the current retry behavior and prevents failed joins). If you’d like, I can: • Walk you through an example flow for either token-based dispatch or a regional orchestrator. • Draft a minimal orchestrator design (endpoints, health checks, dispatch call examples). • Suggest client-side region-detection methods that fit your stack. Which approach sounds closest to what you want to build — explicit token dispatch, regional proxy/orchestrator, or DNS-based routing? That will let me give a short, targeted example you can implement. Sources: Self-hosted deployments | LiveKit Documentation | Agent dispatch | LiveKit Documentation