Explicit dispatch: the server calls createDispatch(room, "harry-voice"), then createSipParticipant for an outbound call through our Twilio trunk.
What happens
On 2026-10-15 at about 16:17 UTC, a real outbound call: dispatch, then SIP participant, in room harry-voice-03d3ab07-f9af-44ab-8148-4c5e12905ac1-1 (RM_87eqy7X4KNZ8). The phone rang and answered, but the agent never joined, so the call was silent. Our backend received no request from the agent process at all, so it never received the job. The agent status was Sleeping before the call.
Reproduction without SIP, at 16:24:11 UTC: lk dispatch create --agent-name harry-voice --room harry-wake-probe-1792081450 returned dispatch AD_kWT2QBqrQowL. The agent stayed Sleeping for more than 95 seconds (polled with lk agent status), and the room had 0 participants.
lk agent logs returns: “The agent has shut down due to inactivity. It will automatically start again when a new session begins.” lk agent restart goes back to Sleeping within seconds.
For comparison, an earlier call the same day at 08:04 UTC (RM_ittbTJquuj2W) worked: the agent joined 0.4 s after the SIP leg. Before that call, the agent had just been deployed and was Running. Project usage this month is 1 agent session minute of 1,000, so we are not at the free-tier limit.
Questions
Should CreateDispatch wake a sleeping Build-plan agent? If so, can you see why AD_kWT2QBqrQowL didn’t?
What counts as “a new session” for waking? Is it the dispatch, a participant joining, or something else?
Is there a supported way to keep one agent warm on Build, or to wake it before an outbound call?
Checked per the docs: worker registers with agentName: "harry-voice"; dispatch has no deployment set (shows blank = production); agent region us-east. Re-ran at 17:46 UTC: lk room create + lk dispatch create --agent-name harry-voice → AD_Lo3APDKZv75K stays listed in lk dispatch list, agent stays Sleeping (replicas 0/1/1) and 0 participants for 77 s. Room creation also produced an unnamed dispatch AD_HY85jZuTYsTK. Could someone check the wake/assignment state for CA_7eUpXLmj9FNk?
I don’t understand why you are getting this error if you are running Node.js agents 1.9.2, the error implies you are running a very old version of Agents. Can you check that?
I’m not saying the old Agent version was the root cause of your issue, but it’s the first thing I was going to suggest updating.
Thanks Darryn. Confirmed we were on @livekit/agents 1.9.2 (exact pin, npm ci from the lockfile), so that notice surprised me. Our sessions start with record: false for privacy. Could that be why the dashboard shows no metrics? I’ve moved to 1.9.3 anyway. The main issue is still that the agent stays Sleeping after CreateDispatch (AD_kWT2QBqrQowL, AD_Lo3APDKZv75K). Can you see why it didn’t wake on CA_7eUpXLmj9FNk?
Update: after moving to @livekit/agents 1.9.3 and redeploying (dXwhNmhEEB5E), a dispatch woke the agent. It went Sleeping, then Running within about 17 s (AD_h2Lyc5AXXQXK, 19:07 UTC). That’s one success after the two failures on 1.9.2, so I can’t yet say the upgrade fixed it. I’ll report back after a real call.
I still see that warning triangle next to your agent name, and I’m unsure why it’s there.
I double-checked and can confirm you ARE using LiveKit agents version 1.9.3, so I think what’s happening is something is going wrong with your agent’s ability to upload the metrics / info and the only reason the dashboard knows about is that your agent is too old, so it gives you that misleading error.
As for what is actually going wrong, I don’t have enough information to say. It’s not the record:false, as that would only affect agent observability. Incidentally, you can disable Observability in the project settings, if you always want it disabled: https://cloud.livekit.io/projects/p_/settings/observability
I wanted to try and reproduce this, as it’s not something I usually test, so using a free account I ran through the getting started steps for Node.js agents at Voice AI quickstart | LiveKit Documentation and deployed my agent into a build account. I couldn’t reproduce your issue, even after specifying record:false just to be sure.
On the assumption that whatever was preventing your agent from waking is related to this strange reporting issue, I think at this point, there are two options:
You recreate the agent from scratch and redeploy with a different agent name.
A coding assistant, connected to our MCP, that has full insight into your agent code (whatever the issue is, I think it will be there): Coding agent support and tools | LiveKit Documentation could probably root cause it.
Sorry that sounds like a bit of a cop out, but without being able to reproduce this, it’s difficult to say for sure.
next to your agent name, and I’m unsure why it’s there.