While I test my self vm hosted livekit instance from my voice bot project I encountered a problem; I can join the room but my agent isn't joining the room. What can be the problem? I tried to generate some tokens for agent to join room? Is it a proper way?

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

what is dispatch I cannot interpret this output of yours: Whether your agent uses automatic or explicit dispatch,

Thanks — great question. I’ll explain “dispatch” clearly and simply and show how the two types (automatic and explicit) work so you can tell which one your agent needs. What “dispatch” means • Dispatch is the mechanism LiveKit uses to tell an agent process to connect to a particular room. • Agents are separate worker processes. They don’t join rooms just because you created a participant token; LiveKit must instruct the agent process to connect. That instruction is the “dispatch.” Two dispatch modes 1) Automatic dispatch • What it is: When an agent is registered without a specific name, LiveKit will automatically dispatch that agent to every new room (or according to default dispatch rules). • When to use: Good for general-purpose agents you want present in all rooms during testing. • How it looks in code: Your agent registration does not set an

agent_name

. The agent runs and waits; when a room is created, LiveKit tells it to join. • How to test: Remove

agent_name

from your agent declaration and create a new room. If the agent server is running and reachable, it should auto-join. 2) Explicit dispatch • What it is: You give an agent a specific name (for example,

"voice-bot-v1"

), then explicitly tell LiveKit to dispatch that named agent to a specific room. Only when that explicit dispatch occurs will that agent connect. • When to use: Useful when you have multiple agent types and want only certain agents in certain rooms. • How it looks in code: Your agent registers with

agent_name="voice-bot-v1"

(or similar). You then create a dispatch via CLI/API or include dispatch rules when creating a participant token for a room to request that named agent. • How to test: Ensure the

agent_name

in your agent code exactly matches the name you dispatch. Then run the dispatch command or API call to send the agent to the room. Why tokens don’t replace dispatch • Participant/JWT tokens authenticate clients to join a room. They do not instruct an agent process to connect. • Agents are connected by the server’s dispatch system, not by receiving a participant token. Simple examples • Automatic dispatch example: ◦ Agent code: registers with no

agent_name

. ◦ Action: Create a room. LiveKit tells the running agent process to join that room automatically. • Explicit dispatch example: ◦ Agent code: registers as

agent_name="my-agent"

. ◦ Action: Run a dispatch command (or call the API) saying “dispatch

my-agent

to room

test-room

.” LiveKit instructs that named agent process to connect to

test-room

. What to check next • Is your agent code registering with an

agent_name

? If yes, you’re in explicit dispatch mode and must dispatch that name. • Is your agent process running and connected to LiveKit? If it’s not running, neither automatic nor explicit dispatch will reach it. • Check agent logs for dispatch-related messages (attempts to connect, rejected dispatch, etc.). If you share: • the agent registration snippet (the line where you register the agent or decorator with

agent_name

, if present), and • any short log lines showing agent startup, I’ll point out whether you’re set up for automatic or explicit dispatch and give the exact command or code to dispatch the agent.

I have this line in my code: if name == "__main__": cli.run_app(WorkerOptions(entrypoint_fnc=entrypoint, agent_name="VoiceAssistantAgent")) I guess I am using explicit dispatch

You're correct — that line shows you're using explicit dispatch. It registers your agent under the name "VoiceAssistantAgent", so LiveKit will only send dispatches to that named agent when you explicitly request it. What this means for you • The agent process will not auto-join every room. It waits until you ask LiveKit to dispatch "VoiceAssistantAgent" to a specific room. • Generating participant tokens will not make the agent join. You must create an explicit dispatch for that agent name. Actionable next steps to get the agent into a room 1. Ensure the agent process is running and connected ◦ Start the agent so it registers with LiveKit: ▪︎ Run your worker/agent process that calls

cli.run_app(...)

. ◦ Check the agent logs to confirm it connected and registered its

agent_name

. 1. Dispatch the named agent to a room ◦ Use the CLI or API to dispatch "VoiceAssistantAgent" to the target room. For example (CLI-style): i. Create or identify the room name (e.g.,

my-room

). ii. Run a dispatch create command specifying the room and `agent_name`: ▪︎ lk CLI:

lk dispatch create --room my-room --agent-name VoiceAssistantAgent

▪︎ Or use the server API that creates a dispatch for that agent name and room. 1. Verify the agent joins ◦ Watch the agent logs after dispatch. You should see the agent receive the dispatch and connect to the room. ◦ Confirm in your LiveKit room that the agent participant is present. Troubleshooting if the agent still does not join • Agent not connected: Confirm the agent process shows a successful registration and is reachable by LiveKit. • Name mismatch: Ensure the dispatch uses exactly

VoiceAssistantAgent

(case-sensitive). • Network/connectivity: Make sure the agent host can reach your LiveKit server (check URLs, ports, TLS). • Dispatch rejected or errors: Share the agent log lines around the time you triggered dispatch and any CLI/API response messages — I can help interpret them. If you want, paste: • The exact agent startup log lines, and • The dispatch command or API call and its response — and I’ll walk through the logs and the dispatch command with you to find the blocker.

explain me this part in detail ho can I do this properly

Great — you’re using explicit dispatch (agent_name="VoiceAssistantAgent"). Below is a clear, step-by-step walkthrough of how to do explicit dispatch properly so your agent will join the room. 1) What explicit dispatch is (short) • Explicit dispatch means you manually tell LiveKit to send your named agent process into a specific room. The agent process must be running and registered under that same name to receive the dispatch. 2) Confirm your agent is registered correctly • Your code must register the agent with the same name:

@server.rtc_session(agent_name="VoiceAssistantAgent")
async def my_agent(ctx: JobContext):
    print(f"Agent joined room: {ctx.room.name}")

• The agent_name in code is case-sensitive and must match exactly what you dispatch. 3) Start the agent process (must be running before dispatch) • Run the agent so it registers with LiveKit. Example dev command:

uv run agent.py dev

• Check the agent terminal/logs for a confirmation like “registered worker” or other startup messages. If you don’t see registration, check LIVEKIT_URL, LIVEKIT_API_KEY, and LIVEKIT_API_SECRET environment variables and network connectivity to your LiveKit server. 4) Dispatch the agent to a room • CLI (quickest test):

lk dispatch create --agent-name VoiceAssistantAgent --room my-test-room

This will create the room if needed and request LiveKit dispatch the named agent to it. • API (programmatic): Use the LiveKit API to create an agent dispatch specifying agent_name and room. Your API call should match the agent name exactly. 5) Verify the agent joined • Check agent logs right after dispatch. You should see something like:

Agent joined room: my-test-room

or other log lines from your entrypoint function. • LiveKit Dashboard: open the room and look for a participant of type AGENT. • Add explicit logging in the agent entrypoint if needed:

@server.rtc_session(agent_name="VoiceAssistantAgent")
async def my_agent(ctx: JobContext):
    print(f"✅ Agent is now in room: {ctx.room.name}")

6) Common reasons a dispatch fails and how to fix • Agent process not running: start it and confirm registration. • Name mismatch: ensure dispatch uses exactly "VoiceAssistantAgent". • Network/firewall issues: ensure agent host can reach your LiveKit server (check ports and TLS). • Dispatch command returns success but agent doesn’t respond: check agent logs for errors or exceptions. • Room connection times out: ensure your agent’s code handles connection and does not exit immediately on startup errors. 7) If you want a quick test flow to confirm everything works 1. Start agent in one terminal: ◦

uv run agent.py dev

1. In another terminal, dispatch: ◦

lk dispatch create --agent-name VoiceAssistantAgent --room test-room

1. Watch agent logs; you should see join confirmation. 8) If it still doesn’t join, please share • The exact dispatch command (or API request) you ran and its response. • The relevant agent startup log lines (especially register/startup and any errors). • The agent_name string from your code (exactly as written). Share those and I’ll read the logs/command output and tell you exactly what to fix. Sources: Build Your First AI Voice Agent in Python: Complete Tutorial | LiveKit | examples/drive-thru | livekit/livekit_composite | DeepWiki | Agent dispatch | LiveKit Documentation | Agents Framework | livekit/livekit_composite | DeepWiki

can I open my self hosted livekit dashboard? If ı can how?

Thanks — great question. Short answer: LiveKit Cloud provides a web dashboard/console, but there isn’t a built-in, one-click dashboard for every self-hosted LiveKit deployment. For self-hosted instances you typically monitor and manage the server using telemetry, metrics, and external tools rather than a managed dashboard. What you can do with a self-hosted LiveKit instance • LiveKit’s open-source SFU includes server-side telemetry and analytics hooks you can export to your own systems. • You can surface that telemetry in a dashboard by exporting metrics to Prometheus/Grafana or another observability stack, or build a custom UI that consumes the telemetry. Practical options to get a dashboard or visibility • Expose Prometheus metrics and use Grafana ◦ Configure your LiveKit server to expose metrics (Prometheus-compatible). ◦ Run Prometheus to scrape those metrics and Grafana to visualize them. ◦ This gives you dashboards for connection counts, packet loss, CPU/ memory, participant counts, etc. • Collect and export telemetry ◦ Use LiveKit’s telemetry/analytics hooks to forward data to your preferred analytics pipeline (ELK, Datadog, etc.). ◦ Build dashboards on top of those exports. • Use the LiveKit Console / Cloud dashboard (if you use LiveKit Cloud) ◦ If you migrate to or use LiveKit Cloud, the cloud console provides a web dashboard for rooms, participants, and agents. ◦ Self-hosted deployments don’t automatically get the Cloud console. • Build a minimal custom dashboard ◦ Query the server’s metrics endpoints and the control API to show active rooms and participants. ◦ This is often sufficient for small deployments. How to proceed (recommended minimal steps) 1. Verify your LiveKit server can expose metrics (check your server config for metrics/telemetry settings). 2. Deploy Prometheus to scrape the LiveKit metrics endpoint. 3. Import or create Grafana dashboards to visualize the scraped metrics. 4. Optionally, forward telemetry to an analytics service (ELK/Datadog) for richer querying. If you want, I can: • Walk you through the exact configuration steps to enable metrics on your LiveKit server (I’ll need to know how you deployed it: Docker compose, Kubernetes, or bare VM). • Suggest a starter Grafana dashboard layout and Prometheus scrape config. • Help interpret specific metrics you care about (room/participant counts, agent dispatch events, latency, packet loss). Tell me how your LiveKit is deployed (Docker, k8s, EC2/VM) and which monitoring tools you already use, and I’ll give the exact commands and sample configs to get a dashboard up quickly. Sources: Agent deployment overview | LiveKit Documentation | Announcing LiveKit Cloud | LiveKit | Running LiveKit on AWS | LiveKit