If we plan to have multiple agents, do we need to have multiple proyects/repos?

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

but how can we deploy them to livekit cloud if they are in the same project?

Thanks — I’m glad you asked. You can absolutely deploy multiple agents from the same LiveKit project to LiveKit Cloud. Here’s how that works and what you’ll need to do. What to do • Give each agent a unique name (for example

inbound-support-agent

,

billing-agent

). When an agent has a specific

agent_name

, it will not receive automatic dispatches — it must be explicitly dispatched. • Deploy each agent separately in LiveKit Cloud using the agent name. For example, use the LiveKit CLI to create deployments tied to each

agent_name

. • Use explicit dispatch to route rooms/sessions to the correct agent: ◦ Create an agent dispatch via the API with the target

agent_name

. ◦ Generate participant tokens that include the

agent_name

(RoomAgentDispatch) so joining participants go to the intended agent. ◦ Or use the CLI (for example:

lk dispatch create --agent-name <name> --room <room>

) or room configuration (e.g.,

roomConfig.agents

) for SIP/automated routing. How scaling and availability work • You can run multiple instances of the same named agent; LiveKit will load balance across them for availability and scale. • Each distinct agent type stays independently deployable and rollbackable, so you can update one agent without impacting others. When you might prefer separate projects/repos • Use separate LiveKit projects to isolate environments (dev/staging/prod) — this is recommended for safety/testing. • You may still choose separate repositories if different teams need isolated CI/CD pipelines or strict repo-level controls. Practical tips • Use environment variables (for example a

LIVEKIT_AGENT_SUFFIX

) during development to avoid name collisions between developer instances. • Use the console/local mode to test agents without touching production LiveKit resources. • Name and dispatch rules should reflect the routing logic you want (by intent, skill, language, etc.) to keep routing simple. If you want, tell me: • The number and types of agents you plan to run. • Whether you need per-environment isolation (dev/staging/prod). • Your preferred dispatch method (API token, CLI, or room config). I’ll give you a concrete example of commands and token payloads to deploy and dispatch your agents based on your answers. Sources: Why do jobs stop after agent rejection? | LiveKit | Agent dispatch | LiveKit Documentation | Pricing | LiveKit | Google AI and LiveKit | LiveKit Documentation | Avoiding crosstalk when multiple developers share a LiveKit project | LiveK..., with interactive elements