can the livekit agents leave the room mid way through the call without the user ending the call - agents have no way to end the call and disconnect from the room, only when user initiates this we can end the call or else agent cannot. what are the problems with this and how does it happen any idea?

Thanks for reaching out, Joshua. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

No as in we have in no place made it so the Agent itself can end the call with tools or code nothing, all this is explicitely started when the user leaves the room, then we kill processes and terminate the room after post call aanalytics and all that stuff. So I want you to find out if there are known bugs that are present within livekit that is causing this as the agent while literally having no access to this possibility manages to leave the room

Thanks — I’m responding to your follow-up asking whether there are any known LiveKit bugs that would make an agent leave a room when you have not implemented any agent-side hangup logic. Short answer • There are no documented LiveKit bugs in the provided sources that cause an agent to autonomously leave a room without an explicit trigger. • The behavior you’re seeing is most likely caused by platform defaults or environment events (auto-close, session options, network failures, or an indirect code path), not a mystery bug that forcibly disconnects agents. Why it can look like an “agent left on its own” • Room auto-termination: LiveKit can implicitly close a room after participants depart (there’s a departure timeout and a sweeper process). When the room is closed, remaining participants (including agents) are disconnected — which looks like the agent “left” https://kb.livekit.io/articles/2412895831-avoiding-room-id-reuse-when-re-creating-rooms-with-the-same-name. • Agent session configuration:

AgentSession

may be configured to close when its linked participant leaves (

close_on_disconnect=True

). That will cause the agent session to end automatically when the user disconnects https://docs.livekit.io/agents/logic/sessions/. • `delete_room_on_close`: If enabled, an agent session ending (even from an error/crash) will delete the room and disconnect everyone — this can appear like the agent caused the closure https://docs.livekit.io/agents/logic/sessions/. • Network / transport failures: ICE/DTLS or other connectivity problems may generate disconnect reasons (e.g., STATE_MISMATCH) that end the session without an explicit hangup by your code https://livekit.io/field-guides/guide/understanding-state-mismatch-disconnect-reason. • Unhandled errors or indirect tool calls: A crash, an unhandled exception, or an LLM/tool invoking a hangup call indirectly could end the agent session even if you didn’t intentionally add hangup logic https://docs.livekit.io/agents/start/telephony/. What to check next (practical steps) 1. Check session/room options: ◦ Confirm whether

close_on_disconnect

or

delete_room_on_close

is enabled for your AgentSession/RoomOptions. If so, those settings explain automatic agent disconnects. 1. Search logs around the disconnect time: ◦ Look for

DeleteRoom

,

close_on_disconnect

, or disconnect reason codes like

STATE_MISMATCH

or transport errors. 1. Verify code paths and tools: ◦ Ensure no background tool, plugin, or function could be calling

session.shutdown()

,

ctx.shutdown()

,

hangup_call()

, or the server

DeleteRoom

API. 1. Inspect network/infra events: ◦ Check for NAT flaps, load balancer timeouts, or ICE failures at the same timestamp as the disconnect. 1. Confirm SDK versions: ◦ Note the LiveKit SDK versions in use (server and client). We don’t have a documented bug in the provided sources, but matching versions helps rule out known past issues. If you’d like, I can help dig further — please share: • SDK version(s) (server & client): e.g., output of

pip freeze | grep livekit

or package.json versions. • A few timestamps and room IDs (RM_xxx) for when this happened. • Relevant log excerpts around a disconnect (server logs, agent logs, and any disconnect reason codes). • Your AgentSession/RoomOptions settings (whether

close_on_disconnect

or

delete_room_on_close

are set). With those details I can help pinpoint whether this was expected platform behavior or something that needs deeper investigation. Sources: Agents telephony integration | LiveKit Documentation | Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Ensuring Unique Room IDs with Dynamic Room Names | LiveKit | Agent session | LiveKit Documentation | An introduction to WebRTC Simulcast

Live kit logs indicate that one this call that was flagged the logs show room deleted after participant left agent left and whatever. but when the user initated we see participant left(client initiated) what are the potential reason for such an issue

Thanks — I’m responding to your note that logs show: participant left (client-initiated), then agent left, then room deleted. Below are the likely explanations and targeted checks you can run to narrow the root cause. Possible reasons for that sequence • Room auto-termination after participant leave ◦ If the user (non-agent participant) left first, LiveKit’s departure timeout and sweeper can close the room shortly after. When the room is closed, remaining participants (the agent) get disconnected and the room is deleted. This looks like agent leaving after the participant left. • Agent session configured to close on linked participant disconnect ◦ If

close_on_disconnect=True

(default behavior for some AgentSession setups), the agent session will end when its linked user leaves. That produces the exact sequence you described. •

delete_room_on_close

enabled for the agent session ◦ If set, any agent session close (including one caused by a participant leaving or an error) will trigger room deletion. • Server-side or orchestration cleanup triggered by your post-call logic ◦ Your backend might listen for client disconnect events and then call

DeleteRoom

after running post-call analytics. This would appear in logs as room deletion after participant left. • Race/ordering in log timestamps ◦ Timestamps or log ordering can make events look sequential even if they are near-simultaneous; check correlated timestamps across systems. • Network/transport issues following participant leave ◦ When the user leaves, ICE/DTLS transitions or a transient transport failure can surface for the agent and cause its session to end; the room may then be cleaned up automatically. • Unhandled error or crash in agent process after participant leaves ◦ The agent process could hit an exception or plugin/tool triggered action (e.g., an LLM/tool calling a hangup) right after the user disconnected, causing the agent to exit and room deletion to follow. Concrete checks to run now 1. Confirm AgentSession/RoomOptions: ◦ Is

close_on_disconnect

set? Is

delete_room_on_close

set? If yes, that explains automatic agent disconnect + deletion. 1. Compare timestamps: ◦ Pull precise timestamps for: participant leave (client-initiated), agent disconnect, and DeleteRoom call. Check for any small deltas or ordering inconsistencies. 1. Search for explicit DeleteRoom calls: ◦ Look for server API calls to

DeleteRoom

around that time in your backend logs (not only LiveKit logs). 1. Inspect disconnect reasons: ◦ In LiveKit logs, check disconnect reason codes for the agent (e.g.,

STATE_MISMATCH

, transport error, or

ROOM_DELETED

). That reason explains whether the agent was forced out by room deletion or disconnected by transport. 1. Check agent process logs: ◦ Look for unhandled exceptions, shutdown hooks, or any function calls to

session.shutdown()

,

ctx.shutdown()

, or

hangup_call()

executed after the participant left. 1. Confirm any post-call cleanup: ◦ Verify whether your post-call analytics or webhooks trigger a DeleteRoom or cleanup job when the user leaves. 1. Verify SDK versions and deployment timing: ◦ Note server/client LiveKit SDK versions and whether any recent deploys or config changes coincide with the event. What I can help with next • If you share: ◦ The exact timestamps and room ID for the incident, ◦ The agent disconnect reason from LiveKit logs, ◦ Whether

close_on_disconnect

or

delete_room_on_close

is enabled, ◦ Any DeleteRoom API call entries from your backend logs, I’ll analyze the sequence and point to the most likely trigger and recommended fix. If you prefer, I can also provide a short checklist and small code snippets to make agent behavior deterministic (e.g., disable

close_on_disconnect

, only delete room from a single server job, add robust logging around DeleteRoom calls). Which would you like to go through next?