Thanks — I’m replying about the error message: "not dispatching agent job since no worker is available." That message means LiveKit tried to hand a job to an agent (for example when a room is created or a participant joins), but there were no agent workers available to take it. Here are the most likely causes and quick checks you can run to narrow it down: • No agent workers running ◦ Check whether any agent process is running. If you haven’t started one, start it (example CLI shown in your environment or agent repo). • Agents running but not connected ◦ Confirm your agent has the correct connection settings: ▪︎

LIVEKIT_URL

(wss:// your server) ▪︎

LIVEKIT_API_KEY

▪︎

LIVEKIT_API_SECRET

◦ Check agent logs for WebSocket connection or authentication errors. • Agents are at capacity ◦ Agents stop accepting new jobs when they reach their load threshold (default ~70%). ◦ Look for load/threshold messages in the agent logs. • Agents were registered with a name (named agents require explicit dispatch) ◦ If your agent code registers with an

agent_name

, it will not be auto-dispatched. Remove the

agent_name

or explicitly dispatch to that name. ◦ Example (automatic dispatch):

@server.rtc_session()  # no agent_name => eligible for automatic dispatch
    async def test_agent(ctx: JobContext):
        await ctx.connect()

• Network or firewall issues ◦ Agents register via WebSocket. Ensure the LiveKit host/port is reachable from the agent hosts and no firewall blocks WebSocket connections. Suggested debugging steps (in order) 1. Check agent registration on the LiveKit server logs ◦ Search for agent connect/register messages or for errors when the server tries to dispatch a job. 1. Inspect agent worker logs ◦ Look for connection errors, auth failures, or “at capacity” / rejection messages. 1. Verify environment variables on each agent host ◦ Confirm

LIVEKIT_URL

,

LIVEKIT_API_KEY

, and

LIVEKIT_API_SECRET

are correct. 1. Test with a minimal agent (no name) to confirm auto-dispatch behavior ◦ Start a minimal agent and see whether jobs are dispatched to it. 1. If you use named agents, confirm your dispatch logic explicitly targets that name ◦ If you relied on auto-dispatch, remove the agent name. To help further, could you share the following details? • Are any agent workers currently running? If yes, what do their logs show when the server attempts to dispatch a job? • Do your agents register with an

agent_name

? • Any recent changes to your server or agent configuration (keys, URL, networking, load thresholds)? • A short snippet of the agent startup/connection logs showing connection or rejection messages (redact secrets). Give me those details and I’ll walk you through the next steps to get jobs dispatching again. Sources: Self-hosted deployments | LiveKit Documentation | Why do jobs stop after agent rejection? | LiveKit