Agent not joining room when dispatched via createRoom agents parameter or createDispatch We're trying to dispatch a named agent to a room for outbound SIP calls. The agent is deployed to LiveKit Cloud, shows as active, and its startup logs confirm it registered with the correct agentName. We've tried two approaches — neither results in the agent joining the room: 1. createDispatch after createRoom — dispatch is created successfully (returns a dispatch ID) but the agent worker shows no activity and never joins. 2. createRoom with agents parameter — room is created but again the agent never joins. We also have a catch-all dispatch rule for our default agent that matches all rooms. That default agent works fine for outbound calls. Could the dispatch rule be interfering with explicit dispatch for the named agent? Environment: - LiveKit Cloud - @strong-father-34524/agents v1.2.2 - livekit-server-sdk v2.15.0 - @strong-father-34524/protocol v1.43.4 What's the correct way to explicitly dispatch a specific named agent to a room created via the API?

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

if the dispatch rule is SIP-only and scoped to inbound prefix, what else would prevent createDispatch from reaching a named agent on an outbound room?

Thanks — I’m responding to your question about whether a SIP‑only, inbound‑prefix dispatch rule would block an explicit

createDispatch

for an outbound room. Short answer • A SIP‑only rule scoped to inbound prefixes should not by itself block an explicit

createDispatch

for an outbound room. If

createDispatch

targets a specific

agent_name

, that explicit dispatch is the intended way to reach a named agent. Other things that can prevent the named agent from joining •

agent_name

mismatch — the dispatched

agent_name

must exactly match the agent’s registered name (case-sensitive). • Conflicting/overlapping rules — another rule (including a broad catch‑all) may match the room first and effectively take precedence. Even if your SIP rule is inbound-only, a separate catch‑all could still apply. • Room name / pattern mismatch — dispatch may expect a particular room identifier or pattern; verify the room passed to

createDispatch

is the one the agent expects. • Missing or incorrect token grants (if using token-based dispatch) — ensure the token includes

RoomAgentDispatch

or relevant grants. • Agent in explicit-dispatch mode — agents registered with an

agent_name

sometimes only respond to explicit dispatches or matching rules; confirm the agent is configured to accept explicit dispatch for that room. • API/client mismatch or versioning — ensure you’re calling the correct AgentDispatch API for your environment and SDK versions. • Agent connectivity or health — the agent may be registered but unable to join rooms due to runtime errors, network restrictions, or crashed worker processes. Check agent logs for join attempts or errors. • Dispatch request payload errors — validate the

createDispatch

request body (missing fields, wrong field names, or malformed JSON). Quick checklist to run now 1. Verify exact

agent_name

used in agent startup logs vs

createDispatch

. 2. Temporarily disable other dispatch rules (especially any catch‑all) and retry. 3. Confirm the

room

value in

createDispatch

exactly matches the outbound room name. 4. Inspect agent logs immediately after

createDispatch

for join attempts or errors. 5. Validate the

createDispatch

request payload and API response (no error, returns dispatch ID). 6. Confirm agent process shows active and healthy (no crashes, network blocks). Example

createDispatch

pattern • Use AgentDispatchService

createDispatch

with

agent_name

and

room

set to the target room (exact names). If you want, paste your request JSON and a short snippet of agent startup logs and I’ll check for mismatches or obvious issues., with interactive elements