https://livekit.io logo
Join Slack
Powered by
Are agent servers a new thing or where workers ren...
# ask-ai
a
Are agent servers a new thing or where workers renamed recently? I didn't check the LiveKit docs for a couple of months and workers seem to be named agent servers everywhere, and the interface is different too. I could swear that this was nowhere to be seen some months ago...
t
Thanks for reaching out, Oleg. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — good question. You're right to notice a change. What’s happening • "Agent server" is now the preferred, more specific term for the process that registers with LiveKit to handle agent jobs (manages job requests, concurrency, scaling, lifecycle). • "Worker" is still used in places (CLI, some SDK examples) as a broader concept or an instance of your agent code, but docs and SDKs increasingly call the managed runtime an AgentServer/agent server. Why it looks different • The docs and interface were updated as the Agents framework matured to clarify roles (job dispatch, prewarm/load control, permissions, etc.), so the UI and examples now show Agent Server-related settings and options. If you want, tell me where you saw "workers" previously (docs page or UI screen) and I’ll point to the matching Agent Server docs or show how to map your existing worker config to the new Agent Server settings. Sources: Agent server options | LiveKit docs | Server lifecycle | LiveKit docs | An open source stack for real-time multimodal AI | Building the all-in-one platform for voice AI agents
a
Do I need to refactor my code? I see that everything changed drastically since then.
t
Thanks — I hear your concern about the drastic changes. Short answer: maybe, but often not a full rewrite. What to expect • If your code uses a generic "worker" concept (simple agent logic that connects, listens for jobs, and handles them), your existing code will often work with minimal changes because "worker" is still a supported concept in examples and CLI. • If you rely on SDK classes, names, or configuration that were renamed (for example 
Worker
→ 
AgentServer
or new 
AgentServer
configuration options like prewarm/load thresholds, request handlers, or permissions), you'll likely need small refactors to adopt the new API names and configuration shape. • If you use advanced lifecycle, concurrency, or new orchestration features, you may want to update logic to take advantage of 
AgentServer
capabilities (prewarm, job isolation, load thresholds). These are optional for basic functionality. What I can help with next • Tell me which SDK/language you’re using (Node, Python, Go, etc.) and share a short snippet of your current worker setup. I’ll point out the exact places to rename or adjust and give specific migration steps.
a
Is there some sort of migration guide somewhere?
t
Yes — there’s a migration guide for Agents 0.x → 1.x. What to read • Migration guide: https://github.com/livekit/livekit_composite/blob/a6d9da94/knowledge_base/how_to_get_help_from_livekit_with_agents.md#how-do-i-migrate-from-agents-0x-to-1x • Examples repo (new patterns): https://github.com/livekit/agents/examples/ • Background/context: https://blog.livekit.io/introducing-livekit-agents-1-0/ Quick note on effort • You’ll typically only need to refactor the outer orchestration (registering your process, entrypoint/handler shape, and config names). Core room logic (STT/LLM/TTS pipelines) usually requires minimal change. Next step • Which SDK/language are you using (Node, Python, Go)? Share a short snippet of your current worker setup and I’ll give precise migration steps. Sources: Building the all-in-one platform for voice AI agents
2 Views
Open in Slack
PreviousNext
Powered by