how can i disable auto dispatch when room is created

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

i want to use dispatch service, but when room is created it keep auto dispatch agent

To help you prevent the automatic dispatch of an agent when a room is created, you’ll want to configure the agent worker to use explicit dispatch by setting the agent_name property in the WorkerOptions. This way, auto-dispatch is disabled, giving you full control over when and how the agent joins a room. Steps to Disable Auto-Dispatch: 1. Set the

agent_name

in your agent's configuration. For example:

const opts = new WorkerOptions({
  agentName: 'my-agent', // Disables automatic dispatch
  entrypointFnc: async (ctx) => {
    console.log('Agent started with metadata:', ctx.job.metadata);
  },
});

2. Once auto-dispatch is disabled, you can manually dispatch the agent using methods like API calls, participant join tokens, or room creation APIs. If you’d like, I’m here to help with more details or examples tailored to your setup—just let me know! Sources: Agent dispatch | LiveKit Docs | Agents telephony integration | LiveKit Docs | livekit-agents/livekit/agents/worker.py | Authentication | LiveKit Docs | livekit/livekit_room.pb.go

should i set entrypointFnc too?

Yes, entrypointFnc is always required when setting up WorkerOptions, no matter if you’re using agent_name or not. This function is really important because it defines the main logic that runs whenever a job is assigned to the worker. Using agent_name doesn’t change the need for entrypointFnc at all. If you’d like, I’m here to help you define this function—just let me know! Sources: Anatomy of an Agent | LiveKit Docs | Making calls using SIP | LiveKit Docs | examples/agent_dispatch.py | agent.py | evaluating-agents/agent_evals.py

i have defineAgent

In Node.js, if you're using defineAgent, you actually don’t need to set entrypointFnc explicitly in WorkerOptions. The great thing is that defineAgent already takes care of including the entry function (which works just like entrypointFnc) and even offers an optional prewarm function. All you need to do is pass the file path that contains the defineAgent export to the agent parameter in WorkerOptions. If you’d like, I’m here to help with more details or examples tailored to your setup—just let me know! Sources: Worker options | LiveKit Docs | Anatomy of an Agent | LiveKit Docs | Silero VAD plugin | LiveKit Docs | agents/src/generator.ts

i hve cli.runApp(new WorkerOptions({ agent: fileURLToPath(import.meta.url), agentName: 'drill-agent' // Disable automatic dispatch, enable explicit dispatch only }));

Your setup using cli.runApp(new WorkerOptions({ agent: fileURLToPath(import.meta.url), agentName: 'drill-agent' })); looks great for disabling automatic dispatch and enabling explicit dispatch. The agent parameter is pointing to the file where your defineAgent logic lives, and the agentName makes sure the agent is only dispatched when you explicitly want it to be. If you'd like, I’m here to help you with explicit dispatch methods or any other configuration questions you might have! Just let me know.

do we need another field in roomconfig?

No additional fields are needed in the RoomConfiguration for explicit agent dispatch if you’ve already set agentName in your WorkerOptions. Explicit dispatch is usually managed programmatically, like with API calls or participant tokens, rather than through the room configuration itself. If you have a particular use case or want me to clarify anything further, please don’t hesitate to ask—I’m here to help!

const supabase = await createClient(); const { data: userRes } = await supabase.auth.getUser(); const user = userRes?.user; if (!user) { throw new Error('Authentication required to request LiveKit token.'); } // Create simple access token for room joining const at = new AccessToken(credentials.apiKey, credentials.apiSecret, { identity: user.id, }); at.addGrant({ roomJoin: true, room: classCode, canPublish: true, canSubscribe: true, }); it this roomconfig good?

Your AccessToken configuration looks great for allowing a user to join a room with publishing and subscribing permissions. Let me walk you through your setup: • roomJoin: This lets the user join the specified room (

classCode

). • canPublish: This gives the user the ability to publish audio, video, or screen share tracks. • canSubscribe: This allows the user to subscribe to media tracks from other participants. This setup is perfect for participants who need full interaction capabilities. If you’re aiming for something like viewer-only access, you can simply set canPublish to false. Feel free to reach out if you’d like me to help you tweak this or if you have any other questions! Sources: Authentication | LiveKit Docs | livekit-api/src/access_token.rs