Agent Memory in LangChain: Short-Term, Long-Term, and Episodic

Last updated: October 13, 2026. Checked against the current LangChain documentation on short-term memory, long-term memory, and memory concepts.

A customer-support agent walks a user through a five-step fix, then—two tickets later—repeats the entire process from scratch. Nothing was “wrong” with the model. The problem was memory: no thread checkpointer to resume context, no scoped store to recall what mattered across threads.

Short answer: LangChain gives agents three kinds of memory. Short-term memory is the conversation state of one thread, saved by a checkpointer. Long-term memory is data saved in a store under namespaces, so it survives across threads and sessions. Episodic memory is a pattern built on long-term memory: storing examples of past successful runs and reusing them as few-shot guidance.

This guide maps how LangChain handles short-term conversation state, cross-thread long-term storage, and episodic retrieval—what each is for, how they fit together, and how to keep them safe. Memory architecture, not just a bigger model, determines reliability, safety, and scale. It reflects the approach the Propelius AI agents team uses on production builds: set the memory scope first, then design retrieval, then add safety rails.

Everything here aligns to current LangChain documentation on short-term memory, long-term memory and stores, and the memory concepts guide. Legacy Conversation*Memory patterns are historical context only. We avoid untested code, pricing, and benchmarks to focus on the patterns you can ship.

Key takeaways

• Short-term memory in LangChain is thread-scoped conversation state managed in AgentState and persisted via a checkpointer for resuming threads.

• Long-term memory stores user- or app-level data across sessions and threads using store backends and namespaces.

• Bounded-history strategies—trimming the last N messages and summarization—prevent context window overflow and distraction for long chats.

• Episodic memory captures and retrieves experience-like traces (past sequences/examples) to guide current behavior.

• Secure memory requires tenant-scoped namespaces, authorization checks, and isolation between threads and tenants; use least-privilege retrieval and audited writes.

What does “agent memory” mean in LangChain?

Agent memory in LangChain is the information an agent keeps from past interactions so it can maintain continuity, avoid repeating work, and make better decisions. It comes in three types:

• Short-term memory: per-thread conversation state, such as messages and variables inside one conversation that the agent can resume later.

• Long-term memory: cross-thread data, such as user or application facts that persist beyond any one thread and are shared across new sessions and channels.

• Episodic memory: experience-like recall, such as compact examples of past successful runs that guide behavior on similar tasks.

These categories come from agent research. The CoALA framework (Sumers et al., 2023) maps human memory types onto language agents, and LangChain's memory guide uses the same model. That guide also describes a fourth type, procedural memory: the instructions an agent follows, which in practice usually means its prompt and code.

Core LangChain entities to know:

• AgentState: the structure that holds short-term state during a thread. By default it keeps conversation history under the messages key.

• Checkpointer: the persistence mechanism for thread state, enabling resumes and branching. InMemorySaver suits development; PostgresSaver suits production.

• Thread ID: the thread_id passed in each call's config, which tells the checkpointer which conversation to load.

• Store: the abstraction for long-term memory across threads, such as InMemoryStore for development or PostgresStore for production.

• Namespace: the scoping key that segments long-term memory by tenant, user, application, or other boundaries.

Out of scope here: provider pricing, performance benchmarks, and untested samples. The focus is on selecting and combining the right memory scopes—and the safety rails that keep them reliable.

Short-term memory: thread state, checkpointers, and safe trimming

Short-term memory in LangChain is the per-thread conversation state, made up of prior turns and variables, that a checkpointer saves so the thread can be resumed at any time. You enable it by passing a checkpointer when you create the agent.

How short-term memory works

1. Add a checkpointer when you create the agent with create_agent. Use InMemorySaver for development and a database-backed option such as PostgresSaver in production.

2. Identify each conversation with a thread_id in the call's config. The checkpointer loads and saves state for that thread.

3. Let AgentState carry the history. By default it keeps messages under the messages key, so turns flow naturally from one step to the next. You can extend the state with your own fields.

Bounded history strategies

Bounded history is essential. With short-term memory enabled, long conversations can exceed the model’s context window. Prevent overflow and distraction by applying one or more of these strategies before each model call:

• Keep the last N messages: preserve immediate context while discarding stale detail. LangChain runs this kind of trimming in a before_model hook.

• Summarize earlier turns: compress older messages into a brief that keeps stable facts and decisions. The built-in SummarizationMiddleware can trigger this at a token threshold.

• Remove stale or irrelevant messages: delete superseded instructions or noise with RemoveMessage, making sure the remaining history is still valid for your model provider.

For deeper patterns and tradeoffs (sliding windows, summarization gates, RAG-backed context), see our companion guide on LangChain memory optimization for AI workflows. For conversational agents specifically, we also cover context window strategies and summarization choices in Building Conversational AI Agents with Context Windows.

How to set scope correctly: threads, namespaces, and cross-thread stores

Set scope by keeping conversation state in threads and saving only durable, cross-conversation facts in a store under narrow namespaces. Cross-thread long-term memory complements per-thread checkpointer persistence: it lets agents carry forward relevant facts beyond a single conversation without bloating the thread’s own history.

Namespaces are the key to safe scope. Long-term memory is saved within custom namespaces, which work like folders, and each memory has a key, which works like a file name. A typical namespace combines identifiers such as tenant ID, user ID, and a memory category. Use them to segment memory so the right agent sees the right data at the right time—and nothing more. LangGraph stores then provide listing and search over items in a namespace, enabling retrieval of long-term records that matter to a new thread.

Treat isolation as a first principle:

• Promote, don't copy. Do not copy raw thread transcripts into global stores. Promote only vetted facts, stable preferences, or durable summaries that hold value across threads.

• Start narrow. Keep namespaces narrow by default; widen scope only with explicit authorization and business logic.

Long-term memory: what to store and when to retrieve

Long-term memory in LangChain is user- or application-level data saved as JSON documents in a store, shared across threads and sessions. Think user preferences, policy constraints, prior approvals, integration handles, and factual records that reduce back-and-forth in new conversations.

Profile or collection

LangChain's memory guide describes two ways to store facts:

• Profile: one document per user that is updated continuously. Easy to read in full, but updates must preserve earlier content, and errors become more likely as it grows.

• Collection: many small, narrowly scoped documents. Less information gets lost and recall tends to be higher, but updating or deleting individual items is harder.

Decide how writes happen

Table: Hot-path versus background memory writes

Decide when retrieval happens

• Bootstrap at the first turn to bring in profiles, constraints, and known context.

• Trigger on identity-specific tasks where user or tenant details shape behavior.

• Fetch selectively when model confidence drops or ambiguity is detected.

Stores can also be configured for semantic search, so the agent retrieves memories by meaning rather than exact key. Tools read and write the store through the agent's runtime, which keeps memory access inside the same authorization checks as other tool calls.

Persist records as JSON-like objects with clear provenance: include source, timestamp, and scope (e.g., tenant, user, app namespace). This makes later auditing and episodic retrieval straightforward and safe.

Episodic memory and experience retrieval

Episodic memory reuses examples of past successful runs to guide current behavior. In practice, this usually looks like few-shot example prompting: compact, labeled traces that show the agent how to solve a similar task end to end. The main challenge, as LangChain's memory guide notes, is selecting the most relevant examples for each input.

When to store episodes:

• After successful multi-step runs that reflect desired behavior.

• After human-approved resolutions that demonstrate the right path through edge cases.

How to retrieve and apply:

• Query by task type, user or tenant, and outcome quality (e.g., “approved,” “resolved”).

• Insert a brief episode summary alongside current short-term state so the model gets just-enough guidance without drowning in old detail.

Guardrails:

• Avoid unlimited recall. Keep episodic examples brief, current, and relevant—aligning with your bounded-history strategy.

• Prefer curated exemplars over raw transcripts to maximize signal and minimize distraction.

To go further on retrieval patterns that complement episodic memory, explore agentic RAG systems beyond basic retrieval.

Tenant isolation and authorization for agent memory

Tenant and user isolation is non-negotiable: give every tenant its own namespaces and check authorization on every memory read and write. Never share a namespace across tenants. Apply deny-by-default policies on both writes (promotion to long-term) and reads (retrieval), allowing access only when identity and role checks pass.

Operational controls to put in place:

• Audit everything. Log all promotions and retrievals with thread_id, namespace, and actor.

• Resume without widening scope. Resuming a thread via a checkpointer should never grant cross-namespace access.

• Redact before promotion. Remove sensitive fields before promoting to shared scopes; keep raw PII in stricter, segregated namespaces if retention is required.

For patterns and anti-patterns by environment and data class, see our guide to tenant data isolation patterns and anti-patterns.

Decision guide: choose short-term, long-term, or hybrid

Use this decision guide to choose the right LangChain memory scope for your scenario, based on its objective, mechanism, and guardrails:

Table: Choosing a LangChain memory scope by scenario

Anchors:

• Short-term = thread-level state in AgentState with a checkpointer.

• Long-term = store-backed records segmented by namespaces.

• Episodic = compact example traces injected as few-shot guidance.

Why these patterns beat naive memory

Table: Naive memory approaches compared with the recommended patterns

LangChain memory vs other agent memory frameworks

LangChain's built-in memory is the most practical choice when your agent already runs on LangChain or LangGraph. Dedicated memory frameworks add more opinionated storage models. As of October 2026, the main options are:

Table: LangChain memory compared with other agent memory frameworks

Framework details are summarized from Atlan's October 2026 comparison. Benchmark scores in this space are mostly vendor-reported, so we don't rely on them here.

When to stay with LangChain's built-in memory:

• Your agent already uses LangChain or LangGraph, so checkpointers and stores share one runtime, one authorization model, and one deployment.

• You need full control over namespaces, tenant isolation, and audit logging.

• Your long-term memory is mostly structured facts and curated episodes rather than a large, evolving knowledge graph.

Consider a dedicated framework when you need time-aware fact history (Zep), self-managed memory tiers (Letta), or a hosted personalization layer you don't want to build (Mem0).

Operational pitfalls and anti-patterns to avoid

• Missing checkpointer. Without a checkpointer, threads cannot be durably resumed. Fix by selecting a production-backed checkpointer and validating thread IDs at creation and resume.

• In-memory persistence in production. InMemorySaver and InMemoryStore lose data on restart. Fix by switching to a database-backed checkpointer and store before launch.

• Storing raw transcripts with PII in shared namespaces. Fix by using per-tenant and per-user namespaces, and redacting or hashing sensitive fields before promotion.

• Unbounded history. Fix by trimming messages and summarizing earlier turns, tied to a token budget gate that runs before model calls.

• Building on legacy memory classes. Older Conversation*Memory classes predate checkpointers and stores. Fix by using a checkpointer for thread state and a store for cross-thread memory in new agents.

• Assuming memory replaces explicit context. Fix by combining targeted retrieval with fresh task context, validations, and tool outputs. Memory supplements situational context; it doesn’t substitute for it.

Build Production-Ready Agent Memory With Propelius

Propelius Technologies' AI Agents & Automation team designs and builds LangChain agents for SaaS products, with memory architecture planned from the first sprint. We help you:

• Choose the right memory scope for each workflow: short-term, long-term, episodic, or hybrid.

• Set up production persistence with database-backed checkpointers and stores.

• Enforce tenant isolation with scoped namespaces, authorization checks, and audit logging.

• Control context costs with trimming, summarization, and curated retrieval.

Talk to the Propelius team about adding reliable, secure memory to your AI agent.

References

• LangChain. Short-term memory. Accessed October 13, 2026.

• LangChain. Long-term memory. Accessed October 13, 2026.

• LangChain. Memory concepts. Accessed October 13, 2026.

• Sumers, T. R., Yao, S., Narasimhan, K., and Griffiths, T. L. Cognitive Architectures for Language Agents (CoALA). arXiv, 2023.

• Packer, C., et al. MemGPT: Towards LLMs as Operating Systems. arXiv, 2023.

• Atlan. Best AI agent memory frameworks in 2026. Updated October 9, 2026.

Frequently Asked Questions

This section answers common questions about short-term, long-term, and episodic memory in LangChain agents.

What is the difference between short-term and long-term memory in LangChain?

Short-term memory belongs to one conversation thread, while long-term memory is shared across threads and sessions.

• Short-term memory: thread-scoped state, especially messages, persisted via a checkpointer so a conversation can be resumed.

• Long-term memory: user- or application-level data stored across sessions and threads, organized into namespaces and backed by stores.

Do I need a checkpointer for short-term memory?

Yes. To add short-term memory you specify a checkpointer when creating the agent. Without it, thread state is not durably persisted and cannot be reliably resumed. Use an in-memory checkpointer for development and a database-backed one in production.

What is the difference between a checkpointer and a store?

A checkpointer saves the state of one conversation thread, while a store saves memories that any thread can read.

• Checkpointer: short-term memory, keyed by thread ID, used to resume and branch conversations.

• Store: long-term memory, organized by namespace and key, used for facts, preferences, and episodes across threads.

How do I keep message history from blowing past the context window?

Trim, summarize, or remove messages before each model call, because long conversations can exceed the context window.

• Keep only the last N messages.

• Summarize earlier turns into a compact brief.

• Remove stale or superseded messages.

For practical tactics and tradeoffs, see our guide on conversational agents and context windows.

How should I scope cross-thread stores safely?

Use per-tenant and per-user namespaces, and authorize every read and write.

• Never share namespaces across tenants.

• Promote only vetted facts and summaries, not raw transcripts.

• Redact sensitive fields before promotion.

• Log every promotion and retrieval for auditing.

Should I write memories in the hot path or in the background?

Write in the hot path when a memory must be available immediately, and in the background when latency matters more. Hot-path writes add latency and complexity to each response. Background writes keep responses fast but may leave other threads briefly without the newest facts.

What counts as episodic memory in practice?

Episodic memory is usually few-shot example prompting drawn from past successful runs.

• Store compact, well-labeled traces after successful or human-approved runs.

• Retrieve them by task type and outcome.

• Insert a brief summary alongside the current conversation state.

Should I use LangChain memory or a framework like Mem0, Zep, or Letta?

Use LangChain's built-in memory if your agent already runs on LangChain, because checkpointers and stores share its runtime and authorization model. Consider Zep for time-aware fact history, Letta for agents that manage their own memory tiers, or Mem0 for a hosted personalization layer.