what is considered an agent deployment on livekit? If I have multiple AI characters that can chat is each one an agent deployment? Which tier would I need if I have 100+ characters

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

it's one user, chatting with an llm. Each "character" has it's own prompt

I understand that managing multiple AI characters can feel a bit overwhelming, so let me help clarify things for you. Each AI character with its own prompt is counted as a separate agent deployment in LiveKit. So, if you have over 100 characters, each one will be considered an individual agent deployment. When figuring out the best tier for your needs, it’s important to think about the total number of agent deployments you have, along with any extra features or usage requirements you might need. If you'd like, I’m here to help you navigate through the options and find the perfect fit for your use case. Just let me know! Sources: Workflows | LiveKit Docs | examples/src/multi_agent.ts | Workflows | LiveKit Docs | examples/voice_agents/restaurant_agent.py | main.py

so an agent has a fixed codebase / fixed prompt? I can't hot swap the prompts?

Hi there! I wanted to share that LiveKit agents can have dynamic prompts, and you can actually switch prompts on the fly during runtime using the

update_instructions

method. Just a heads up, when you update the prompt this way, the conversation restarts—so the active context resets, but your session history stays intact. If you're looking to keep the conversation flowing smoothly while changing prompts, a great option is to use the

update_agent

method. This lets you switch to a new agent with a different prompt, and the best part is the new agent inherits the previous conversation context, making the transition feel seamless. Feel free to reach out if you'd like me to walk you through examples or provide more details on how to use these methods. I'm here to help! Sources: Workflows | LiveKit Docs | livekit-plugins/livekit-plugins-ultravox/livekit/plugins/ultravox/realtime/... | basics/change_agent_instructions.py | Workflows | LiveKit Docs

lets say a customer wants to chat with one character (one prompt), then switch characters (second prompt). can I do one agent, then do update_instructions and reset the history / fetch the right history

I'm happy to help you switch between characters (prompts) within a single agent! You can do this smoothly by using the

update_instructions

method to dynamically change the prompt. If you'd like to reset the conversation history or pull up specific history for your new character, the

update_chat_ctx

method is your friend—it lets you clear the context or load a customized one. For instance, you might create a new

ChatContext

with the system message tailored for your new character and apply it. Or, you could trim or filter the existing history to keep just the parts that matter. This way, you have flexible control over both the prompt and the conversation context. Please feel free to reach out if you'd like me to share some detailed code examples or if you want me to walk you through the implementation step-by-step. I'm here to help! Sources: plugins/openai/src/realtime/realtime_model.ts | Workflows | LiveKit Docs | Workflows | LiveKit Docs | multi-agent/long_or_short_agent.py | livekit-agents/livekit/agents/voice/generation.py

If I have 20 users talking to 4 characters, how many agents do I need?

Could you please help me understand a bit better? Are your users interacting with all 4 characters at the same time, or is each user assigned to just one specific character? Knowing this will really help us figure out how to count the agents in your situation. Thanks so much!

each user has an instance of the character, but they all use the same base prompt but different historical context

Thanks for sharing your scenario! So, if you have 20 users and each one interacts with 4 characters—each character having its own instance but using the same base prompt with different historical contexts—you’d be looking at a total of 80 agents. That’s because every user-character interaction counts as its own agent deployment, even though they share the base prompt. Please feel free to reach out if you’d like me to explain this further or if you need any help getting everything set up. I’m here for you!

in the scale plan, you allow 4 agent deployments, but 50+ concurrent agent sessions. How does that relate to this?

Thank you for your question! On the LiveKit Scale plan, the limit of 4 agent deployments means you can have up to 4 different agent versions or services running. For instance, each deployment could be a unique type of agent or a different version of the same agent. When we talk about the 50+ concurrent agent sessions, this refers to the total number of active sessions happening at the same time across all your deployments. So, even though you can have 4 unique deployments, together they can support up to 50 live sessions simultaneously. If you find that your needs go beyond 50 concurrent sessions, no worries! You can easily request an increase through your project settings in the LiveKit Cloud dashboard. Please feel free to reach out if you'd like me to walk you through that or if you have any other questions—I’m here to help! Sources: LiveKit Pricing | Deploy and scale agents on LiveKit Cloud | Quotas and limits | LiveKit Docs

give me examples of what concurrent sessions means if we only have 5 different agent versions/services running

Concurrent sessions are basically the number of active, simultaneous interactions happening across all your agent deployments. Let me share a few examples to make it clearer: • Imagine you have 5 different agent versions or services running, and each one is handling 10 active user sessions at the same time—that adds up to 50 concurrent sessions altogether. • Or, if one agent version is managing 30 active sessions and another is handling 20, that still totals 50 concurrent sessions, no matter how many other deployments might be idle. • If you happen to go over the 50 concurrent session limit, new sessions won’t be allowed unless you’ve asked for and received an increase to your concurrency limit. Please feel free to reach out if you'd like me to explain anything further or help you manage your deployments and sessions—I’m here to help!

if we are handling 50 concurrent sessions, does each session have it's own context on a single agent?

Absolutely! Each concurrent session in LiveKit has its own isolated context, even when a single agent is handling multiple sessions. This means every session runs in its own separate process, keeping things like conversation history and user-specific data completely independent from one another. Also, while each session starts fresh by default, the full session history is saved and can be accessed or shared between agents whenever needed. This setup really helps balance isolation with the flexibility you might need when managing multiple sessions at once. Please feel free to ask if you'd like me to explain anything further or provide some examples—I’m here to help! Sources: Inside a session | LiveKit Docs | Inside a session | LiveKit Docs | livekit-agents/livekit/agents/voice/agent_session.py | Workflows | LiveKit Docs | Worker lifecycle | LiveKit Docs

why would I ever need more than 2 agents then

I completely understand why you might be wondering about needing more than 2 agents. Usually, this comes up when you want different agents to handle specific tasks, configurations, or use cases. Here are a few common situations where having multiple agents can really make a difference: • Specialized Behavior: Each agent can be designed to focus on a particular role—like customer support, technical troubleshooting, or sales—so they can use the best prompts, tools, and workflows for that purpose. • Different Models or Tools: Sometimes, you might want to use different language models, text-to-speech voices, or integrations depending on the task. Separate agents can help manage these variations smoothly. • Versioning: If you’re testing new features or rolling out updates gradually, having multiple versions of the same agent can be really helpful for A/B testing. • Scalability: For larger systems, multiple agents can share the workload, which helps keep things running efficiently and reliably. • Dynamic Handoffs: When your application needs to switch between different roles—like moving from a greeting agent to a billing agent—multiple agents can make those transitions feel natural and seamless. If you’d like, I’m here to help you think through how these ideas might fit your specific needs. Just let me know!