Skip to main content
AI applications need memory to share context across multiple interactions. In LangGraph, you can add two types of memory:

Add short-term memory

Short-term memory (thread-level persistence) enables agents to track multi-turn conversations. To add short-term memory:

Use in production

In production, use a checkpointer backed by a database:
You need to call checkpointer.setup() the first time you’re using Postgres checkpointer
Setup To use the MongoDB checkpointer, you will need a MongoDB cluster. Follow this guide to create a cluster if you don’t already have one.
You need to call checkpointer.setup() the first time you’re using Redis checkpointer.
Setup To use the Oracle checkpointer, you will need an Oracle AI Database instance. A local container (for example gvenzl/oracle-free:23-slim) or an Oracle Autonomous Database in OCI both work.
You need to call checkpointer.setup() the first time you’re using the Oracle checkpointer.

Use in subgraphs

If your graph contains subgraphs, you only need to provide the checkpointer when compiling the parent graph. LangGraph will automatically propagate the checkpointer to the child subgraphs.
You can configure subgraph-specific checkpointing behavior. See subgraph persistence for details on persistence levels including interrupt support and stateful continuations.

Add long-term memory

Use long-term memory to store user-specific or application-specific data across conversations.

Access the store inside nodes

Once you compile a graph with a store, LangGraph automatically injects the store into your node functions. The recommended way to access the store is through the Runtime object.

Use in production

In production, use a store backed by a database:
You need to call store.setup() the first time you’re using Postgres store
You need to call store.setup() the first time you’re using Redis store.
Setup To use the Oracle store, you will need an Oracle AI Database instance — the vector index used for semantic search requires Oracle AI Vector Search.
You need to call store.setup() and checkpointer.setup() the first time you’re using the Oracle store and checkpointer.
Enable semantic search in your graph’s memory store to let graph agents search for items in the store by semantic similarity.

Manage short-term memory

With short-term memory enabled, long conversations can exceed the LLM’s context window. Common solutions are: This allows the agent to keep track of the conversation without exceeding the LLM’s context window.

Trim messages

Most LLMs have a maximum supported context window (denominated in tokens). One way to decide when to truncate messages is to count the tokens in the message history and truncate whenever it approaches that limit. If you’re using LangChain, you can use the trim messages utility and specify the number of tokens to keep from the list, as well as the strategy (e.g., keep the last max_tokens) to use for handling the boundary. To trim message history, use the trim_messages function:

Delete messages

You can delete messages from the graph state to manage the message history. This is useful when you want to remove specific messages or clear the entire message history. To delete messages from the graph state, you can use the RemoveMessage. For RemoveMessage to work, you need to use a state key with add_messages reducer, like MessagesState. To remove specific messages:
To remove all messages:
When deleting messages, make sure that the resulting message history is valid. Check the limitations of the LLM provider you’re using. For example:
  • Some providers expect message history to start with a user message
  • Most providers require assistant messages with tool calls to be followed by corresponding tool result messages.

Summarize messages

The problem with trimming or removing messages, as shown above, is that you may lose information from culling of the message queue. Because of this, some applications benefit from a more sophisticated approach of summarizing the message history using a chat model. Summary Prompting and orchestration logic can be used to summarize the message history. For example, in LangGraph you can extend the MessagesState to include a summary key:
Then, you can generate a summary of the chat history, using any existing summary as context for the next summary. This summarize_conversation node can be called after some number of messages have accumulated in the messages state key.
  1. We will keep track of our running summary in the context field
(expected by the SummarizationNode).
  1. Define private state that will be used only for filtering
the inputs to call_model node.
  1. We’re passing a private input state here to isolate the messages returned by the summarization node

Manage checkpoints

You can view and delete the information stored by the checkpointer.

View thread state

View the history of the thread

Delete all checkpoints for a thread

Database management

If you are using any database-backed persistence implementation (such as Postgres, Redis, or Oracle) to store short and/or long-term memory, you will need to run migrations to set up the required schema before you can use it with your database. By convention, most database-specific libraries define a setup() method on the checkpointer or store instance that runs the required migrations. However, you should check with your specific implementation of BaseCheckpointSaver or BaseStore to confirm the exact method name and usage. We recommend running migrations as a dedicated deployment step, or you can ensure they’re run as part of server startup.