Server lifecycle

Overview

When LiveKit server receives a dispatch request, it routes the request to an available agent server. The first available agent server accepts the job and starts the agent session. An overview of the server lifecycle is as follows:

1. Agent server registration: Your agent code registers itself as an "agent server" with LiveKit server, then waits on standby for requests.
2. Job request: A dispatch request is sent to LiveKit server — either explicitly via the AgentDispatchService API or automatically when a user connects to a room. LiveKit routes the request to an available agent server, which accepts it and starts a new process to handle the job. To learn more, see agent dispatch.
3. Job: The job initiated by your entrypoint function. This is the bulk of the code and logic you write. To learn more, see Job lifecycle.
4. LiveKit session close: By default, a room is automatically closed when the last non-agent participant leaves. Any remaining agents disconnect. You can also end the session manually.

The following diagram shows the agent server lifecycle:

Server features

Some additional features of agent servers include the following:

• Agent servers automatically exchange availability and capacity information with LiveKit server, enabling load balancing of incoming requests.
• Each agent server can run multiple jobs simultaneously, running each in its own process for isolation. If one crashes, it doesn't affect others running on the same agent server.
• When you deploy updates, agent servers gracefully drain active LiveKit sessions before shutting down, ensuring sessions aren't interrupted.
• If an agent disconnects from an active room unexpectedly (for example, due to an out-of-memory error or crash), LiveKit server detects the disconnection within approximately 15 seconds and automatically dispatches a new agent to the room.