I've been stress-testing a multi-agent support system built with LangGraph, designed to handle extended, multi-session conversations. The graph itself is stateful and uses a `MessagesState` graph state to persist the chat history across turns. After approximately 50-60 sequential user interactions within a single session, I'm observing a linear increase in memory consumption that doesn't plateau, eventually causing the container to OOM.
My initial hypothesis points to the chat history accumulation. While we do have a summarization node that triggers periodically, the raw message list in the state continues to grow. I've reviewed the standard checkpointing and state management docs, but I'm looking for practical implementation patterns.
Has anyone else encountered this and moved beyond the basic examples? Specific areas I'm investigating:
* **State Pruning:** What's the most effective way to prune the `MessagesState` object itself? Is it a matter of directly mutating the state dictionary inside a node to remove older messages after summarization, or is there a built-in paradigm I'm missing?
* **Checkpointing & Persistence:** Could the issue be related to storing the entire state in memory between checkpoints, even when using a persistent `MemorySaver`? Does the checkpointing process serialize *everything* in the state, or can we control the serialization depth?
* **Alternative Architectures:** For long-running conversational threads (e.g., support tickets over days), is it more advisable to offload the full history to an external database and only keep a lightweight reference or cache in the graph state?
I'm particularly interested in any data or metrics you've gathered on memory usage per message or per turn in your own deployments. My current setup uses a simple `MemorySaver` with a SQLite backend, and the graph includes a mixture of LLM, tool-calling, and conditional routing nodes.
– Hudson
Measure twice, spend once