My agent stop getting dispatched to the room I am creating, it was working yesterday, but today I see a bunch of agent dispatch error in the UI. how can I further investigate?

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

project id: p_4k0wlfhdg2b agent id: CA_c2QBpAyzaHK4 connection details: { "room": "room-for-stanislas.duprey+witness@proton.me-456613", "roomID": "", "participant": "stanislas.duprey+witness@proton.me", "pID": "PA_Vakzgdnw2fmB", "source": "microphone", "muted": false, "enabled": true, "kind": "audio", "streamID": "6fe54733-7a5c-4313-82ce-7fdc6f32d4c4", "streamTrackID": "6fe54733-7a5c-4313-82ce-7fdc6f32d4c4" } Connected to room at 2026-02-28T142816.472Z

LOGS:
lk agent logs --config livekit.staging.toml
Using project [witney-ai]
Using agent [CA_c2QBpAyzaHK4]
Waiting for deployment to start...
Waiting for deployment to start...
Waiting for deployment to start...
Waiting for deployment to start...
Waiting for deployment to start...
{"message": "starting worker", "level": "INFO", "name": "livekit.agents", "version": "1.3.11", "rtc-version": "1.0.23", "timestamp": "2026-02-28T14:28:00.571615+00:00"}
{"message": "preloading plugins", "level": "INFO", "name": "livekit.agents", "packages": ["livekit.plugins.turn_detector", "av"], "timestamp": "2026-02-28T14:28:00.571806+00:00"}
{"message": "HTTP server listening on :8081", "level": "INFO", "name": "livekit.agents", "timestamp": "2026-02-28T14:28:00.594121+00:00"}
{"message": "initializing process", "level": "INFO", "name": "livekit.agents", "pid": 64, "timestamp": "2026-02-28T14:28:01.013982+00:00"}
{"message": "initializing process", "level": "INFO", "name": "livekit.agents", "pid": 67, "timestamp": "2026-02-28T14:28:01.032629+00:00"}
{"message": "initializing process", "level": "INFO", "name": "livekit.agents", "pid": 72, "timestamp": "2026-02-28T14:28:01.047288+00:00"}
{"message": "initializing process", "level": "INFO", "name": "livekit.agents", "pid": 78, "timestamp": "2026-02-28T14:28:01.065585+00:00"}
{"message": "process initialized", "level": "INFO", "name": "livekit.agents", "pid": 64, "elapsed_time": 3.46, "timestamp": "2026-02-28T14:28:04.476511+00:00"}
{"message": "process initialized", "level": "INFO", "name": "livekit.agents", "pid": 67, "elapsed_time": 3.45, "timestamp": "2026-02-28T14:28:04.477858+00:00"}
{"message": "process initialized", "level": "INFO", "name": "livekit.agents", "pid": 72, "elapsed_time": 3.44, "timestamp": "2026-02-28T14:28:04.483087+00:00"}
{"message": "process initialized", "level": "INFO", "name": "livekit.agents", "pid": 78, "elapsed_time": 3.42, "timestamp": "2026-02-28T14:28:04.487949+00:00"}
{"message": "registered worker", "level": "INFO", "name": "livekit.agents", "agent_name": "", "id": "CAW_JwRcZpaa4FMw", "url": "<https://witney-ai-1q274tgl.livekit.cloud>", "region": "US East B", "protocol": 16, "timestamp": "2026-02-28T14:28:04.571743+00:00"}

with livekit.staging.toml being:

[project]
  subdomain = "witney-ai-1q274tgl"

[agent]
  id = "CA_c2QBpAyzaHK4"

Thanks — and thanks for the detailed info. I’m looking at your project/agent details and the agent logs you shared. I’ll walk through what the logs show, what to check next, and a few targeted questions to narrow this down. What I’m responding to: your agent (CA_c2QBpAyzaHK4) registers successfully but rooms are showing agent dispatch errors and agents stopped being dispatched. What the logs show (facts) • The agent process starts and initializes multiple workers (pids 64,67,72,78). • A worker successfully registers: id = CAW_JwRcZpaa4FMw, agent_name = "" (empty), URL = https://witney-ai-1q274tgl.livekit.cloud, region = US East B, protocol 16. • The CLI waited for deployment to start several times, then the normal startup logs appear and registration succeeds. What this implies • The agent is running and at least one worker has successfully registered with the LiveKit cloud — so worker availability and basic connectivity look OK. • The registered worker has an empty

agent_name

. That means the agent is registered for automatic dispatch (no explicit

agent_name

) unless your code sets an

agent_name

elsewhere. Targeted checks to do next 1. Confirm whether your rooms are created with explicit agent dispatch: ◦ If your agent code uses an

agent_name

in the

@server.rtc_session

decorator, dispatch must be explicit (rooms must include

RoomConfiguration.agents

). But your worker shows

agent_name = ""

— if your rooms request an explicit agent name, they won’t match this worker. ◦ Please check the room creation/token code and share the

RoomConfiguration.agents

portion (or confirm whether you rely on automatic dispatch). 1. Check the UI error messages and timestamps: ◦ What exact dispatch error text appears in the UI and at what times? (Paste the UI error lines if possible.) Those messages often include the reason (no matching agents, all busy, job rejected, etc.). 1. Search logs for job rejection or dispatch errors: ◦ Look for log lines containing “reject”, “rejected”, “dispatch”, “job”, or “error” around the room connection time (2026-02-28T142816.472Z). ◦ If any job was rejected, note the rejection reason and whether your agent returned

terminate=True

(rejections can prevent future dispatching). 1. Verify worker capacity and concurrency: ◦ Are all workers healthy or are some cycling/crashing? You have 4 initialized pids; confirm they remain up after startup. If workers are busy or repeatedly rejecting, dispatch can fail. 1. Confirm credentials and project mapping: ◦ You’re using subdomain

witney-ai-1q274tgl

and agent id CA_c2QBpAyzaHK4 — those match the registration URL in the logs. That indicates correct project/agent mapping. If you can, please provide • The UI dispatch error text(s) and timestamps. • Any additional agent logs around 142816 and after (search for lines with “dispatch”, “job”, “reject”, or “error”). If there are job rejection entries, paste them. • The snippet of code or token payload you use when creating the room (particularly any

RoomConfiguration.agents

or

agent_name

usage). Quick likely causes based on what I see • Mismatch between the agent’s

agent_name

(empty) and the room requesting an explicit agent name. • Agent worker rejecting jobs (look for rejection logs) which can halt further dispatch. • Intermittent worker crashes after registration (confirm workers remain running). Next steps I can take for you • If you paste the UI error and any rejection logs, I’ll interpret them and give precise remediation. • If you paste the room creation/token snippet, I’ll verify whether your rooms will match the registered worker (automatic vs explicit dispatch) and show how to fix it. If you prefer, start by pasting the exact UI error message and any nearby log lines containing “reject” or “dispatch” — I’ll analyze those immediately and recommend the concrete fix.

I don't see any error, only the agent is not connecting to the room

Thanks — I see you don’t get a UI error, the agent registers successfully, but it still doesn’t join the room. I’ll walk through the most likely causes based on the logs you provided and give precise next steps you can run now. What I’m responding to: your agent CA_c2QBpAyzaHK4 registers (worker CAW_JwRcZpaa4FMw) but does not connect to the room even though the participant connected at 2026-02-28T142816.472Z. What the logs/metadata tell us (facts) • Agent started, initialized 4 worker processes and registered a worker to your project URL. • The registered worker’s agent_name is empty ("") — this means the worker is available for automatic dispatch unless an explicit agent name is required by the room token. • You show a participant connect time (2026-02-28T142816.472Z) but no dispatch join lines in the agent logs you pasted. Likely root causes to check (in order) 1. Mismatch between room’s requested dispatch and worker agent_name ◦ If the room (or token) requests an explicit agent_name but your worker registered with an empty name, it won’t match and won’t be dispatched. 1. Room never actually asked for an agent ◦ Agents are dispatched when a participant joins the room with an agent dispatch configured. If the participant joined but no RoomConfiguration.agents (or explicit dispatch) was included, the agent won’t be asked to join. 1. Silent job rejection or timeout that didn’t appear in your excerpt ◦ An agent can accept then fail to connect, or reject a job. Those entries may be after the startup logs and are not included above. 1. Worker capacity / crash after registration ◦ The worker registered but could have crashed or become busy before the participant join. Your snippet shows initial registration only. Concrete steps to run now (quick checks) 1. Confirm how you create/join the room ◦ Paste the snippet (or describe) how you generate the participant token and whether you include

RoomConfiguration.agents

or an explicit

agent_name

. ◦ If you do not include

RoomConfiguration.agents

, automatic dispatch is required (agent_name must be empty on the worker). If you DO include an agent_name, it must exactly match the worker’s

agent_name

. 1. Search agent logs for dispatch/connect events around the participant timestamp ◦ Run:

lk agent logs --config livekit.staging.toml --since "2026-02-28T14:27:30Z" --tail 500

and look for lines containing: dispatch, job, accept, connect, reject, error. • Paste any lines that mention "dispatch", "job", "accept", "connect", or "reject". 1. Confirm worker health after registration ◦ Run:

lk agent status --id CA_c2QBpAyzaHK4
     lk agent list

Verify number of workers, their status, and that none are reported as crashed or 0 replicas. 1. If you used explicit agent_name in code, show that code ◦ Example places to check: ▪︎

@server.rtc_session(agent_name="...")

in the agent code ▪︎ Any

RoomConfiguration(agents=[RoomAgentDispatch(agent_name="...")])

or token payload when creating a participant token What I can do once you return results • If you paste the log lines found in step 2, I’ll interpret them and point to the exact reason (mismatch, rejection, timeout, crash). • If you paste the room/token snippet from step 1, I’ll confirm whether it should match the registered worker and show the minimal change to make it work. • If status shows workers down or 0 replicas, I’ll give the exact restart or config command to restore replicas. Short checklist you can follow immediately • If you expect automatic dispatch: ensure no

agent_name

is set on the agent and include no explicit agent in the token. • If you use explicit dispatch: ensure the agent registers with that exact

agent_name

(or change the token to the empty name to match the registered worker). • Share the log lines from the time around 142816 and the room-creation/token snippet. If you paste the outputs for steps 1–3 here (token/room creation code + the log lines +

lk agent status

output), I’ll analyze them and give the exact change to fix dispatch so the agent will join the room. Sources: Agent dispatch | LiveKit Documentation | Build a multilingual voice agent that automatically switches languages | Li... | Why do jobs stop after agent rejection? | LiveKit | Agents telephony integration | LiveKit Documentation | CreateRoom() is taking too long | LiveKit

here is the token creation code:

'use server'

import { ConnectionDetails } from '@/types'
import { RoomConfiguration } from '@livekit/protocol'
import { AccessToken } from 'livekit-server-sdk'

const API_KEY = process.env.LIVEKIT_API_KEY
const API_SECRET = process.env.LIVEKIT_API_SECRET
const AGENT_NAME = process.env.AGENT_NAME

export async function getToken(
  email: string,
  mockTestimonyId: string,
  questionIndex = 0
): Promise<ConnectionDetails> {
  if (API_KEY === undefined) {
    throw new Error('LIVEKIT_API_KEY is not defined')
  }
  if (API_SECRET === undefined) {
    throw new Error('API_SECRET is not defined')
  }
  if (AGENT_NAME === undefined) {
    throw new Error('AGENT_NAME is not defined')
  }
  console.log(`Creating token for room with agent ${AGENT_NAME}`)
  const roomName = `room-for-${email}-${~~(Math.random() * 1000000)}`
  const participantName = email
  const participantToken = await getParticipantToken(
    participantName,
    roomName,
    mockTestimonyId,
    questionIndex
  )

  return {
    roomName,
    participantToken,
    participantName,
  }
}

async function getParticipantToken(
  participantName: string,
  roomName: string,
  mockTestimonyId: string,
  questionIndex: number
) {
  const at = new AccessToken(API_KEY, API_SECRET, {
    identity: participantName,
    // Token to expire after 10 minutes
    ttl: '10m',
  })
  at.addGrant({ roomJoin: true, room: roomName })

  at.roomConfig = new RoomConfiguration({
    agents: [
      {
        agentName: AGENT_NAME,
        metadata: JSON.stringify({ mockTestimonyId, questionIndex }),
      },
    ],
  })
  return at.toJwt()
}

Thanks — this is very helpful. I’m responding to the token creation code you just shared and the earlier logs showing the worker registered with an empty

agent_name

. That combination explains why the agent isn’t being dispatched. What’s happening (summary) • Your token explicitly sets a RoomConfiguration with an agent entry:

agentName: AGENT_NAME

. • The agent worker that registered (from your logs) has

agent_name = ""

(empty). • Because your token requests an explicit agent name, the dispatcher looks for workers registered with that exact

agent_name

. An empty-name worker will not match, so the agent is never dispatched to the room even though the worker is registered. Two clear ways to fix this Choose one depending on whether you want named (explicit) agents or automatic dispatch. Option A — Use explicit named agents (recommended if you need specific agent routing) 1. Ensure the agent process registers with the same

agent_name

value you put in the token: ◦ Set the AGENT_NAME in the agent runtime environment (the agent code must call

@server.rtc_session(agent_name="...")

or equivalent so the worker registers with that name). 1. Restart/deploy the agent so the worker registers with that agent_name. Confirm with:

lk agent status --id CA_c2QBpAyzaHK4
   lk agent list

Then check logs for a registration line showing

agent_name = "<your-agent-name>"

. 1. Continue using your token code as-is (it will now match the named worker). Option B — Use automatic dispatch (quickest if you don’t need explicit routing) 1. Remove the agents block from the RoomConfiguration so the token does not request an explicit agent: ◦ In your getParticipantToken(), remove or skip setting

at.roomConfig

or set it without agents. ◦ Example: simply call

at.addGrant({ roomJoin: true, room: roomName })

and don’t set

roomConfig

. 1. Because the worker registered with an empty

agent_name

, the dispatcher will automatically assign that worker to the room when a participant joins. Recommended next checks to confirm behavior 1. After choosing A or B, create a new token and join the room. Then gather these logs: ◦ Agent logs around the participant join time:

lk agent logs --config livekit.staging.toml --since "2026-02-28T14:27:30Z" --tail 500

Look for lines mentioning

dispatch

,

job

,

accept

,

connect

, or

reject

. 1. Verify worker registration shows the expected name:

lk agent logs --config livekit.staging.toml  # watch startup logs

and confirm a registration line like:

"registered worker", "agent_name": "<your-agent-name>"

(or

""

for automatic). 1. If you choose Option A and the agent still registers with an empty name, check the agent runtime config/code where

agent_name

should be provided and ensure the environment variable is set and the code reads it. If you want, I can: • Point out the exact minimal code change for Option B to remove agent dispatch from the token. • Help verify agent registration logs after you restart the agent (paste new registration log lines and I’ll confirm). • If you prefer Option A, tell me the value of AGENT_NAME you want to use and paste the agent startup logs after restart — I’ll check that the worker registered with that name. Which approach would you like to take — make the agent named (explicit dispatch) or switch to automatic dispatch?