nice-bear-83533
03/17/2026, 2:04 PMtall-airline-16756
03/17/2026, 2:05 PMtall-airline-16756
03/17/2026, 2:05 PMctx.shutdown() in your agent’s entrypoint. This cleanly closes the session and disconnects the agent from the room.
• If you want the room deleted immediately when the session ends, set delete_room_on_close: True in RoomOptions / RoomInputOptions. Otherwise the room remains and follows the normal lifecycle.
• After shutdown you can also explicitly delete the room via RoomServiceClient.deleteRoom() if you need to force-disconnect remaining participants.
Room lifecycle notes
• The room does not necessarily close just because the agent leaves while other participants (e.g., the user) remain. By default rooms remain open and follow the configured departure/timeout behavior.
• The platform has a departure_timeout / grace-period behavior for when the last participant leaves; if no participants remain the room will be closed after that timeout unless you’ve deleted it earlier or set delete_room_on_close.
How the client reacts
• When the agent leaves or the room is closed, the SDK emits a disconnected room event. Clients should listen for that event and handle UI/cleanup (for example: show a “call ended” screen, stop local media, or attempt reconnection).
• If you call the DeleteRoom API (or the room is deleted via options), connected clients will be removed and receive the same disconnection behavior from the SDK.
If you’d like, I can:
• Show a short code example of using ctx.shutdown() in agents-js.
• Show how to listen for the disconnected event on the client and perform UI cleanup.
Which would help you most next?
Sources: Job lifecycle | LiveKit Documentation | Agent session | LiveKit Documentation | Server lifecycle | LiveKit Documentation | Server-side | livekit/livekit_composite | DeepWiki, with interactive elementsnice-bear-83533
03/17/2026, 2:13 PMtall-airline-16756
03/17/2026, 2:14 PMRoomServiceClient.deleteRoom()).
• You configured the agent/session to delete the room on shutdown by setting delete_room_on_close: True in RoomOptions / RoomInputOptions when ending the agent session.
What to keep in mind for your app
• If you want the room to end as soon as the agent leaves even when the user remains, enable delete_room_on_close or call deleteRoom() from your server when the agent shuts down.
• If you want users to continue in the room without the agent (e.g., for post-call actions), leave the room open and handle agent departure on the client (listen for the disconnected event and update UI accordingly).
If you want, I can show:
• A short code snippet for setting delete_room_on_close, or
• An example of listening for the disconnected event on the client to handle agent leave events.
Which would you prefer?
, with interactive elementsnice-bear-83533
03/17/2026, 2:14 PMtall-airline-16756
03/17/2026, 2:14 PMdisconnected event on the client and whether there's any delay between the agent calling ctx.shutdown() and the client receiving that event. I'll cover both and include a short client-side example.
Listening for the disconnected event
• The client SDK emits a disconnected room event when the client is disconnected from the room (this occurs when the agent leaves, when the room is deleted, or when the client itself loses connection).
• To handle this, register an event listener on the Room (or the equivalent room object in your client SDK) and run your cleanup/UI logic when you receive disconnected.
Example (pseudo/JS-style)
• Register the handler after joining the room:
room.on('disconnected', (reason) => {
// reason may describe why (e.g., 'server_closed', 'network')
// Stop local media, show "call ended", navigate away, etc.
console.log('Room disconnected:', reason);
stopLocalTracks();
showCallEndedUI();
});
Timing / delay between agent shutdown and client event
• There can be a short, typically small delay between the agent calling ctx.shutdown() and clients receiving disconnected. This is because:
◦ The agent's session needs to close on the server, and then the room state/update is propagated to connected clients.
◦ If you explicitly delete the room (e.g., RoomServiceClient.deleteRoom() or delete_room_on_close: True), the server removes participants which triggers immediate disconnection events to clients.
◦ If the agent simply disconnects but the room stays open for remaining participants, clients only see the agent leave (a participant-left event) rather than a full disconnected for the user — disconnected appears for a client when that client itself is disconnected or when the room is closed/deleted.
• In practice: expect near-real-time delivery (usually under a second), but network latency and processing can add small delays. If you need guaranteed immediate force-disconnect behavior for remaining clients, delete the room from the server when the agent shuts down.
What you should do in your client
• Listen for both:
◦ Participant updates (to detect the agent leaving): e.g., participant-removed or participant state change events.
◦ The disconnected event (to detect the room being closed or the client being disconnected).
• Implement UI that handles both cases:
◦ Agent left but room still exists → show “agent has left” and allow user actions.
◦ Room deleted / client disconnected → show “call ended” and perform full cleanup.
Would you like a concrete code sample for:
• The exact client SDK you’re using (web/JS, React, or native), or
• An example that listens for both participant removal and room disconnected and shows the UI flows?, with interactive elements