bumpy-needle-9917
03/17/2026, 12:57 PMtall-airline-16756
03/17/2026, 12:57 PMtall-airline-16756
03/17/2026, 12:57 PMagent_name so you have redundancy and higher availability if one worker fails.
• Running more agents on one machine increases concurrency, but be sure to size CPU, memory, and network capacity so processes don’t compete for resources.
If you want, tell me:
• Are you planning a self-hosted or LiveKit Cloud setup?
• How many agents/workers you want to run and the machine specs (CPU, RAM)?
I can then suggest a simple process layout and resource-sizing guidance or a sample startup command/config based on your environment.
Sources: Server lifecycle | LiveKit Documentation | Self-hosted deployments | LiveKit Documentation | Agents Framework | livekit/livekit_composite | DeepWiki, with interactive elementsbumpy-needle-9917
03/17/2026, 12:59 PMtall-airline-16756
03/17/2026, 12:59 PMagent_name so the service looks like a single logical agent while handling many concurrent sessions.
What that means in practice:
• A single container should run one agent server process. That agent can spawn isolated processes per job to handle concurrency, but all jobs are instances of the same agent logic.
• To scale capacity or provide redundancy, run multiple containers (or workers) with the same agent_name. LiveKit will balance incoming sessions across those workers.
• If your goal is to have multiple specialized agents (different roles/logic), deploy them as separate agents and coordinate them via tools/handoffs or by having one agent call another.
If you want, tell me:
• Are you trying to run multiple identical workers for capacity, or different specialized agents that need to collaborate?
• Are you using LiveKit Cloud or self-hosted LiveKit? (You mentioned Cloud, but confirming helps me give exact command/config examples.)
I can then suggest:
• A simple container startup pattern for running multiple worker processes of the same agent, or
• Recommended architecture for multi-agent workflows (how to split roles and wire them together) with example calls/tools. Sources: Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Agents Framework | livekit/livekit_composite | DeepWiki | Self-hosted deployments | LiveKit Documentation | Server lifecycle | LiveKit Documentation | examples/voice_agents | livekit/livekit_composite | DeepWiki, with interactive elementsbumpy-needle-9917
03/17/2026, 1:01 PMAre you trying to run multiple identical workers for capacity, or different specialized agents that need to collaborate?yes
Are you using LiveKit Cloud or self-hosted LiveKit?livekit cloud
tall-airline-16756
03/17/2026, 1:01 PMagent_name. Each worker handles jobs as isolated processes.
• For multiple specialized agents, deploy them as separate agent deployments and coordinate them (tools, handoffs, function calls) so they can collaborate.
Recommended approaches
1) Scale capacity (multiple identical workers)
• Deploy one container image that runs your agent server logic for a given agent_name.
• Run multiple instances (containers) of that same image on LiveKit Cloud. All instances register under the same agent_name and LiveKit will balance jobs across them.
• Inside each container the agent can spawn per-job isolated processes, increasing concurrency; but those are all instances of the same agent logic.
• This model gives redundancy and high availability.
2) Multi-agent collaboration (specialized agents)
• Create separate agent deployments for each specialized role (for example: orchestrator_agent, qa_agent, nlp_helper).
• Deploy each role as its own container/agent on LiveKit Cloud (one primary agent process per container).
• Coordinate between agents using:
◦ Tools or function calls where one agent invokes another agent’s capability.
◦ Explicit handoffs: one agent finishes then calls the next agent via an API/tool.
◦ Shared state or task queues if you need loose coupling.
• This keeps roles modular, testable, and independently scalable.
3) If you want the “appearance of a single agent” but with multiple workers and roles
• Use a single logical agent_name for capacity (many identical workers).
• For specialized behavior, have that logical agent call specialized services or microservices (which can themselves be separate agents) rather than trying to embed multiple agent deployments inside one container.
Practical next steps I can help with
• If you want capacity: I can provide a sample container startup command and a recommended worker count based on your expected concurrent sessions (tell me expected concurrency and machine size).
• If you want collaboration: I can sketch a simple multi-agent workflow example (call sequence and tool definitions) showing how one agent can call another.
• If you want hybrid guidance: describe which parts need to be identical workers and which are specialized roles, and I’ll recommend a deployment topology.
Which of the next steps do you want to try first?
, with interactive elements