Hi guys, I want to know if have the posibility to add in my agent, something that allow my agent retry run again if it down.
The problem with the initialization back again, and when it happen, the server just chash…
Its posible? Or not?
Other point: Can I set to my agent stop and restart some connection? e.g: One user is 15 hours connected, so, the system restart this connection to clear memory usage…
Or just add the max of context chat sended to LLM (I want to know if it’s posible), to don’t use a lot of memory from server too.
Is a lot of questions, but I didn’t found on docs.
Hey, are you self-hosting LiveKit server? Or using LiveKit cloud? It sounds like you’re self-hosting LiveKit server, but wanted to check
Yes, but the control of memory I need to my agent server (not livekit local, the agent normal, that run tools, etc)
And the crash, I need understand what is making the server crash with timeout message.
You might want to take a look at the documentation for Agent Server, Agent server overview | LiveKit Documentation, including all of the subsections on lifecycle and dispatch.
For agent memory, you might want to take a look at this: Self-hosted deployments | LiveKit Documentation
Docs for self-hosted LiveKit server start here: Self-hosting overview | LiveKit Documentation but it’s not my area of expertise
Can I set max of context to my agents? Like, last 15 messages?
You could truncate the messages on on_user_turn_completed, Pipeline nodes and hooks | LiveKit Documentation, and calling update_chat_ctx with the truncated messages, or you could summarize the context, similar to as described here: Agents and handoffs | LiveKit Documentation.
But, if the root cause of your crash is really the agent context getting too large, it feels like this is more of a band-aid than a fix.
About server crashing during the initialization, I tested and this error happen sometimes when the user try connect with the agent, I don’t know why.
About the max of context: It is more to previne an user with the same connection for long hours, usina a lot of memory from backend because the high number of context