Thanks — I hear your concern about an agent unexpectedly leaving a LiveKit room. I’ll explain the common causes, whether agents rejoin automatically, and practical steps you can take to detect, diagnose, and recover from this. Why an agent might unexpectedly leave • Network/connectivity loss: If the agent’s network or WebRTC media path is disrupted (ICE/STUN keep‑alives stop), the server may time out and disconnect the participant after ~20 seconds. • Server-side disconnection reasons: The server can close a participant for reasons such as

CONNECTION_TIMEOUT

,

DUPLICATE_IDENTITY

,

ROOM_DELETED

,

MIGRATION

, or

CLIENT_INITIATED

. • Agent process crash or failure: If the agent process crashes or is terminated, that session disconnects. • Room deletion or lifecycle events: If the room is deleted (manually or via a setting like

delete_room_on_close

), participants are removed. Is there built-in rejoin logic? • There is no automatic rejoin for agents. Once a participant disconnects, LiveKit does not automatically reconnect them — reconnect/rejoin must be implemented by your application if you need that behavior. • You can programmatically reconnect by calling connection routines in your agent code (and issuing a fresh token if required), but that is custom application logic rather than built-in client behavior. How to handle and recover 1. Detect the disconnect quickly ◦ Listen for SDK events (e.g., `disconnected`/room participant left events) and server-side webhooks (like

participant_left

) so your backend knows the agent left. ◦ Log the

closeReason

or disconnect reason reported by the server to get the root cause. 1. Implement reconnection / recovery (if you need the agent to rejoin) ◦ On disconnect, attempt a controlled rejoin flow: i. Obtain a fresh token if required. ii. Re-establish the connection and re-subscribe to tracks. iii. Restore any agent state (e.g., published tracks, UI state). ◦ Add exponential backoff and a maximum retry window to avoid tight reconnect loops. 1. Graceful shutdown and lifecycle handling ◦ Use shutdown hooks or job lifecycle callbacks in your agent to cleanup or persist state when a process is shutting down. ◦ Avoid settings that delete rooms unless intended; make sure server shutdown drains jobs rather than abruptly killing sessions. 1. Monitoring and diagnostics ◦ Capture and store disconnect reasons and network logs for post‑mortem. ◦ Use connection test utilities to check TURN/STUN and ICE health when you see repeated disconnects. ◦ Look out for duplicate identity joins (same identity connecting elsewhere) which can force a prior participant out. Next steps I can help with • If you can share the disconnect reason (e.g.,

closeReason

from your logs) or SDK event payload, I can help interpret it and recommend targeted fixes. • If you want a sample reconnection flow for your agent language/SDK (JavaScript, Swift, Flutter, etc.), tell me which SDK you use and I’ll outline a practical rejoin routine. Would you like to start by sharing the disconnect reason or the SDK your agent uses? Sources: Understanding the STATE_MISMATCH Disconnect Reason | LiveKit | Server-side | livekit/livekit_composite | DeepWiki | Job lifecycle | LiveKit Documentation | client-sdk-flutter | livekit/livekit_composite | DeepWiki | client-sdk-swift | livekit/livekit_composite | DeepWiki