An AI agent’s context window is what the model can use in the current request; it is not a durable record of earlier conversations. To give an agent memory that lasts, save selected state outside the active context, define who or what that state belongs to, and retrieve the relevant parts when needed. Frameworks such as LangGraph and application-controlled files illustrate ways to do this, but the right design depends on your application.
Why a context window is not memory
The context window holds the content available to a model for a particular request. It can include the current prompt, conversation history, and other material supplied by the application. When a conversation grows, its history may exceed that window. Even before that happens, sending the entire history every time can make requests slower, more costly, or less focused, as the LangChain short-term memory guide explains.
As an Amazon Associate I earn from qualifying purchases.
Persistent memory is information stored separately and made available again later. The model can only use that information when the application retrieves it or otherwise includes it in the active context. In other words, persistence and context are related but distinct: persistence keeps information available between requests; context is what the model can see now.
Choose the scope of memory first
Before choosing a storage mechanism, decide which interactions should be able to use each piece of information. A conversation’s working state is not necessarily appropriate to share with every conversation from the same user, and application-wide information may not belong in an individual user’s memory.
#1 Best Overall
| Memory scope | What it is for | Documented pattern |
|---|---|---|
| Thread or conversation | State needed to continue or resume a particular interaction | LangGraph checkpointer |
| Across threads | Application-defined information that should be available beyond one conversation | LangGraph store |
| Application-managed files | Information saved between sessions and read or changed through application-provided file operations | Anthropic memory tool |
These are distinct design patterns, not a ranking. LangGraph describes checkpointers for thread-level graph state and stores for application-defined information shared across threads; its documentation says the two can be used together. Its persistence documentation and memory guide explain the distinction.
Three ways to persist information
Use a checkpointer for thread continuity
A checkpointer saves graph state associated with a thread, allowing an interaction to continue or resume. This is a useful fit when the agent needs the state of the same conversation, rather than a shared profile or knowledge base. The LangGraph persistence documentation describes checkpointers as one of its two complementary persistence systems.
Use a store for cross-thread information
A store holds application-defined information outside a single thread’s graph state. This can make selected information available across conversations, according to the scope and access rules the application establishes. It is not the same as automatically sharing every conversation transcript.
Use files when the application should control operations and storage
Anthropic’s memory tool documents a file-based approach: Claude can create, read, update, and delete persistent files through application-implemented file operations. The application controls the storage infrastructure and what those operations permit. The tool is designed to retrieve stored information when needed rather than requiring the complete file history in every request. See the Anthropic memory tool documentation.
Make persistence survive the process
A memory object held only in a running process can disappear when that process stops. An in-memory example therefore does not, by itself, establish durability across restarts. For production short-term memory, LangChain recommends configuring a database-backed checkpointer; its guide demonstrates that approach. The specific backend should follow your application’s requirements for durability, access, and operations rather than treating one database choice as universal.
Build a retrieval loop, not an ever-growing prompt
Persistent storage only helps if the application can select useful information and bring it into the current request. A practical flow is:
- Identify the scope. Decide whether the information belongs to one thread, a user across threads, or the application.
- Save selected state. Persist the details needed for future work, using a checkpointer, store, or application-controlled files as appropriate.
- Retrieve when relevant. Before a later model call, load the state pertinent to that request and include it in the active context.
- Update or remove stale information. Define how the application changes stored state when circumstances change, and how it handles information that should no longer be retained.
This separates what is retained from what is sent to the model on each turn. It also avoids assuming that a full transcript must be replayed for an agent to benefit from past interactions.
Free tools Windows power users keep installed
One-click scans. No signup required.
What the phrase “we fixed it” can—and cannot—mean here
The official documentation establishes several ways to add persistence, but it does not identify the implementation used by the team behind this title. Without the project’s code or author notes, it would be misleading to claim that the fix used a particular framework, database, vector store, or summary scheme. The reliable general answer is architectural: persist information outside the context window, scope it deliberately, and retrieve it into context when the agent needs it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
