I need to give my agent a long-term memory. What's the best framework for integrating both short-term and long-term memory solutions?

When giving an AI agent both short-term (working/conversational memory) and long-term (persistent/episodic/semantic memory) capabilities, there isn't a single "one-size-fits-all" winner. Instead, the best framework depends on whether you want a dedicated memory layer that plugs into any agent or an orchestration framework that manages memory natively.

The top-tier frameworks specialized in handling short- and long-term agent memory include:

• • Mem0: Often described as an "intelligent memory tier for AI," Mem0 is purpose-built to provide personalized, cross-session memory. It manages short-term context alongside a multi-layered long-term architecture (using vector stores, entity graphs, and historical logs) so the agent continuously learns and updates user preferences over time.
• • Letta (formerly MemGPT): Inspired by operating system memory management, Letta treats LLM context like RAM and external storage like disk memory. It is exceptional for agents that need to autonomously manage their own memory paging—deciding what to keep in short-term active context and what to write to long-term storage when conversations scale indefinitely.
• • Zep: Built specifically for production conversational AI, Zep excels at maintaining fast, low-latency short-term chat histories while asynchronously extracting facts, summaries, and embedding vectors into a robust long-term knowledge store. It’s a favorite for user-facing assistant applications.
• • LangGraph / LangMem: If you are already building your agent logic using LangChain's ecosystem, LangGraph combined with LangMem provides primitives for managing stateful short-term threads alongside optimized long-term reflection and memory distillation.

Which one should you pick?

• Choose Mem0 if you want the easiest drop-in memory API that works across different LLM providers and instantly gives your agent cross-session user recall.
• Choose Letta if your agent needs deep, autonomous control over its own memory space and you expect very long, unbounded running contexts.
• Choose Zep if you are building enterprise chat applications requiring high-performance temporal and semantic recall.

To help narrow down the ideal choice, tell me:

• What is the primary use case for your agent (e.g., personal assistant, customer support, data analyst)?
• Are you already using a specific orchestration stack like LangChain, AutoGen, or raw API calls?

For a production AI agent, the best approach is usually not one memory database, but a layered memory architecture where short-term state, long-term facts, and retrieval mechanisms have different responsibilities. Modern agent memory systems increasingly separate these concerns rather than treating “memory” as just chat history or a vector store.

A strong default architecture looks like this:

                 User / Environment
                         |
                         v
              +---------------------+
              |   Agent Runtime     |
              +---------------------+
                         |
        +----------------+----------------+
        |                                 |
        v                                 v
 Short-Term Memory                 Long-Term Memory
 (working context)                 (persistent knowledge)
        |                                 |
        |                         +-------+--------+
        |                         |                |
        v                         v                v
 Conversation state          Semantic memory   Episodic memory
 Tool results                Facts/preferences Past experiences
 Current goals               Embeddings        Event history
 Scratchpad                  Graph relations   Summaries

Recommended stack

1. Short-term memory: keep it inside your agent framework

Use short-term memory for:

• Current conversation
• Active task state
• Tool outputs
• Intermediate reasoning artifacts
• Current plan

Typical implementations:

• In-memory state object for simple agents
• Checkpointing for resumable workflows
• Conversation summarization when context grows too large

If you use a graph/workflow agent framework, use its native state management first. For example, LangGraph-style state/checkpoint systems are designed around preserving execution state while an agent runs. Framework-native memory is often the simplest starting point.

---

2. Long-term memory: split it into types

Avoid storing everything in a vector database. Different memories need different storage models.

Semantic memory (facts)

Examples:

• "User prefers concise answers"
• "Company uses PostgreSQL"
• "Customer's billing cycle is monthly"

Store in:

• Key-value database
• Document store
• Knowledge graph
• Vector index for fuzzy retrieval

Episodic memory (experiences)

Examples:

• "Last time the agent helped deploy this service, the issue was caused by an expired token"
• "User rejected solution X and chose solution Y"

Store:

• Event database
• Timeline store
• Vector search over summarized episodes

Procedural memory (learned behavior)

Examples:

• "Always validate customer IDs before calling API X"
• "For this team, use their preferred deployment workflow"

Store:

• Rules
• Policies
• Agent instructions
• Skill libraries

---

Framework choices

There is no universal winner; choose based on your architecture. Recent agent-memory systems have diverged into several approaches: memory APIs, temporal knowledge graphs, framework-native memory, and full agent runtimes.

Best general-purpose add-on: Mem0

Good when:

• You already have an agent
• You want user personalization
• You want memory extraction handled for you

Architecture:

Agent
 |
Memory API
 |
+-------------+
| Vector DB   |
| Graph DB    |
| Metadata DB |
+-------------+

---

Best for long-running autonomous agents: Letta

Good when:

• Agents run for days/weeks
• The agent should manage its own memory
• You want explicit memory tiers

Conceptually:

Core Memory
  |
Recall Memory
  |
Archival Memory

---

Best if you already use LangChain/LangGraph: LangMem

Good when:

• Your orchestration is already in that ecosystem
• You want memory integrated into workflows

---

Best for time-sensitive knowledge: temporal graph memory

For agents dealing with changing entities:

• Customers
• Projects
• Organizations
• People
• Policies

A temporal graph can answer:

"What did we believe about this customer last month?" rather than only:

"What facts match this query?" Systems such as Zep/Graphiti-style approaches focus on this temporal relationship layer.

---

A production pattern I would recommend

For most serious agents:

                Agent
                  |
        Memory Manager Layer
                  |
    +-------------+--------------+
    |             |              |
    v             v              v
 Redis/Postgres  Vector DB    Graph DB
 short state     retrieval    relationships

                  |
                  v

          Memory Consolidator
                  |
       Extract → Summarize → Merge → Forget

The important missing piece in many implementations is memory management:

• Decide what is worth saving
• Detect contradictions
• Update old memories
• Expire stale information
• Track confidence/provenance

Research is increasingly moving toward agents that actively manage memory operations (store, retrieve, update, discard) rather than relying only on retrieval heuristics.

My default recommendation

If I were building a new agent today:

• Agent framework: LangGraph or a similar workflow runtime
• Short-term state: framework checkpoint store + Redis/Postgres
• Long-term semantic memory: Mem0 or a custom Postgres + pgvector layer
• Complex domains: add a temporal knowledge graph
• Memory controller: a dedicated service that decides what gets written and retrieved

Start simple:

1. Store conversation summaries.
2. Extract durable user/domain facts.
3. Retrieve only relevant memories per task.
4. Add graphs and temporal reasoning only when your domain requires it.

The biggest mistake is giving an agent "infinite memory." Good agents need selective memory, not total recall.

For most serious agents:

                Agent
                  |
        Memory Manager Layer
                  |
    +-------------+--------------+
    |             |              |
    v             v              v
 Redis/Postgres  Vector DB    Graph DB
 short state     retrieval    relationships

                  |
                  v

          Memory Consolidator
                  |
       Extract → Summarize → Merge → Forget

The important missing piece in many implementations is memory management:

When building an AI agent that requires both short-term memory (immediate context, scratchpads, and active dialogue history) and long-term memory (cross-session user preferences, semantic knowledge, and episodic recall), choosing the right framework depends on whether you want a state-machine approach , an OS-inspired memory manager , or a dedicated memory layer.

The top-performing frameworks handle short-term and long-term memory through distinct architectures:

• 1. LangGraph (Best for production-grade state and custom memory graphs) — LangGraph approaches agent memory via explicit state management and checkpointing. Short-term memory is managed via a rolling message queue inside the graph's state, while long-term memory is integrated by attaching external vector stores or custom database nodes that persist data across threads. It gives you microscopic control over what gets saved, summarized, or discarded.
• 1. Letta / MemGPT (Best for autonomous, OS-like memory management) — Inspired by operating system virtual memory, Letta (formerly MemGPT) explicitly teaches the agent how to manage its own memory hierarchy. It divides memory into core memory (short-term, editable scratchpads for persona and current context) and archival/recall memory (long-term vector and relational databases). The agent runs function calls to read, write, and search its own memory tiers autonomously.
• 1. Zep (Best as a specialized long-term memory and knowledge graph layer) — Rather than a full agent orchestration framework, Zep is an infrastructure layer designed specifically for LLM memory. It automatically handles short-term conversation summarization, embeds and indexes long-term facts, and extracts semantic knowledge graphs from dialogue history asynchronously. You can plug Zep into LangChain, LlamaIndex, or custom agent loops.
• 1. CrewAI (Best for multi-agent role-based setups) — CrewAI features built-in memory management systems out-of-the-box, combining short-term memory (for recent task outputs), long-term memory (storing historical execution insights in a vector database), and entity memory (remembering specific people, places, or concepts mentioned across tasks).

Which one should you pick?

• Choose LangGraph if you want deep architectural control, deterministic transitions, and robust debugging via LangGraph State Management.
• Choose Letta if your agent needs to autonomously decide what to remember or forget over extended, months-long autonomous lifecycles.
• Choose Zep if you already have an agent framework you like (or custom code) and just need a powerful, drop-in API for long-term semantic search and fact extraction.

To help narrow down the best fit, tell me:

• Are you building a single autonomous agent or a multi-agent team?
• What database or vector store infrastructure (e.g., PostgreSQL, Pinecone, Redis) are you already using?

If you’re building an agent from scratch today, I’d use LangGraph as the orchestration/runtime layer, with a dedicated long-term memory layer behind it. The key is not to treat “memory” as one database or one vector store.

My recommended architecture

                    ┌─────────────────────┐
                    │       Agent         │
                    │  LLM + tools + loop │
                    └──────────┬──────────┘
                               │
                 ┌─────────────┴─────────────┐
                 │                           │
          Short-term memory           Long-term memory
          (current thread)            (across sessions)
                 │                           │
          LangGraph state             Memory service
          + checkpointer              (Mem0 / Zep / etc.)
                 │                           │
             PostgreSQL              Vector / graph / DB

Short-term memory should contain the active conversation, tool results, intermediate state, and task context. LangGraph calls this thread-level memory and persists it through a checkpointer.

Long-term memory should contain things worth remembering after the conversation ends: user preferences, stable facts, past decisions, important experiences, learned procedures, etc. LangGraph's store abstraction is explicitly designed for this cross-thread memory.

What I'd choose

Mem0 is particularly attractive if you already have an agent and simply want to add durable memory without handing over the whole agent architecture. Its model is essentially extract → store → retrieve relevant memories → inject them into the agent context.

The important part: don't save every conversation

I'd structure long-term memory into at least three categories:

• Semantic memory — “User prefers concise answers.”
• Episodic memory — “We solved the deployment problem by changing X.”
• Procedural memory — “For this user's workflow, perform steps A → B → C.”

This distinction is also reflected in modern agent-memory architectures.

Then use a pipeline like:

User message
     ↓
Retrieve relevant long-term memories
     ↓
Assemble current context
     ↓
Agent reasoning + tools
     ↓
Response
     ↓
Memory extraction
     ↓
Decide:
  ├── discard
  ├── update existing memory
  └── create new durable memory

The memory extraction/update step is crucial. Otherwise your database becomes a dumping ground of stale, contradictory facts.

For example:

Old:
"user prefers Python"

New:
"user is currently migrating this project from Python to TypeScript"

You don't want retrieval to blindly return both as equally authoritative.

One architecture I'd actually ship

If you're using Python/TypeScript and want something pragmatic:

                    LangGraph
                       │
          ┌────────────┴────────────┐
          │                         │
    Checkpointer                 Memory API
          │                         │
      PostgreSQL                  Mem0
          │                         │
    thread state          ┌────────┴─────────┐
                          │                  │
                       facts             episodes
                          │                  │
                       vector             metadata

Use Postgres for authoritative application state, rather than putting business-critical state into the memory system.

Use Mem0 for things like:

{
  "user_id": "123",
  "memory": "User prefers technical explanations with code examples.",
  "type": "preference",
  "confidence": 0.94
}

And retrieve only memories relevant to the current task.

That gives you a very clean separation:

State = what the agent is doing. Memory = what the agent has learned. Knowledge/RAG = what the agent can look up. That's a much better mental model than simply calling everything “memory.”

When I'd choose something else

I'd pick Zep/Graphiti if your agent needs to reason heavily about relationships and facts that change over time—for example, “Alice worked at Company A from 2021–2024 and Company B afterward.” Temporal knowledge graphs are particularly suited to this.

I'd pick Letta if the agent itself is the product and you want memory/context management deeply embedded into a persistent autonomous-agent runtime rather than adding memory to an existing orchestration system.

I'd use LangGraph's native Store alone if your memory requirements are relatively straightforward and you want fewer dependencies. LangGraph explicitly supports combining its checkpointer for short-term memory with its Store for long-term memory.

So my default recommendation is: LangGraph + Postgres checkpointer + Mem0, with a deliberate memory extraction/update policy. That's probably the best balance of flexibility, maintainability, and not locking your entire agent architecture into a memory vendor.

If you tell me what kind of agent you're building (coding agent, personal assistant, customer-support agent, autonomous researcher, etc.) and your stack (Python/TypeScript, LangChain, OpenAI Agents SDK, CrewAI, etc.), I can recommend a concrete memory architecture and schema.

Building a robust agent memory requires splitting responsibilities into two clear layers: Short-Term (Working Memory) for immediate turn-by-turn context and Long-Term (Episodic/Semantic Memory) for persistent cross-session facts and preferences.

Because orchestration frameworks (like LangGraph or CrewAI) handle the active reasoning loop differently than dedicated memory storage layers , the "best" choice depends on whether you prefer a native framework approach or a specialized, drop-in memory infrastructure.

Top Framework Options & Architectures

1. Mem0 (Best Drop-In Memory Layer)
   • How it works: Acts as an independent, plug-and-play memory API . It automatically extracts, compresses, and updates user preferences or past interactions using hybrid vector search and metadata filtering.
   • Why choose it: It is framework-agnostic . You can attach Mem0 to LangGraph, CrewAI, Mastra, or custom runtimes without locking your long-term storage to a specific orchestration engine.
2. LangGraph + LangMem (Best Native Ecosystem)
   • How it works: Uses LangGraph checkpointers for short-term thread state and LangMem for managing semantic/episodic memory namespaces and context compression.
   • Why choose it: Ideal if you are already building complex, stateful workflows inside the LangChain ecosystem and want tightly integrated persistence with minimal external microservices.
3. Zep / Graphiti (Best for Temporal & Knowledge Graphs)
   • How it works: Constructs dynamic temporal knowledge graphs where facts carry validity windows and entity relationships change over time.
   • Why choose it: Excellent for agents that need to track complex state changes across days or weeks (e.g., "who authorized X, when, and why") rather than relying purely on flat vector similarity.
4. Letta / MemGPT (Best for OS-Level State Management)
   • How it works: Employs an operating system-like virtual memory model where the agent explicitly manages its own core memory (in-context) and archival memory (out-of-context) via tool calls.
   • Why choose it: Best for long-running autonomous agents that need direct, self-directed control over what to page in or evict from their active window.

Recommended Production Blueprint

Instead of saving raw, bloated chat logs as long-term memory (which is expensive and introduces noise), use a two-tier architecture:

• Short-Term Tier: A local or managed checkpointer/buffer handling the immediate conversation trace for the active thread.
• Long-Term Tier: An asynchronous background process that extracts distilled facts, preferences, or summaries on turn completion and saves them into a vector/graph store (like Mem0 or Zep) for future injection.

To help narrow down the best fit, tell me:

• Are you building in Python or TypeScript?
• Is your orchestration layer already using LangGraph, CrewAI, or a custom setup?
• Does your agent need to remember individual user preferences or complex organizational data/graphs?

For an agent that needs both short-term (working/session) memory and long-term (persistent) memory, the best architecture is usually not a single database. Treat memory as a layered system:

                ┌─────────────────────┐
                │       Agent LLM      │
                └──────────┬──────────┘
                           │
              ┌────────────┴────────────┐
              │   Memory Orchestrator  │
              └────────────┬────────────┘
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
 Short-term           Long-term          Knowledge
 Memory               Memory             Memory
        │                  │                  │
 Conversation       User facts,        Documents,
 state, tasks,      preferences,       entities,
 tool outputs       experiences        relationships
        │                  │                  │
 Redis /            Mem0 / Zep /       Vector DB +
 LangGraph          Letta              Graph DB
 state

The leading approaches today generally fall into three categories: memory APIs (Mem0), temporal knowledge graphs (Zep/Graphiti), and agent-managed memory runtimes (Letta).

Recommended stack patterns

1. General-purpose production agent (my default recommendation)

Short-term

• LangGraph state/checkpointing
• Redis or Postgres for active session state

Long-term

• Mem0 as a memory layer

Architecture:

User message
    ↓
Retrieve relevant memories
    ↓
Inject into context
    ↓
Agent reasons + acts
    ↓
Extract new memories
    ↓
Update long-term store

Why this works:

• Easy to add to an existing agent
• Handles user preferences and personalization well
• Avoids dumping entire chat history into the context window

Mem0 is commonly chosen when you want a drop-in memory layer across different agent frameworks.

---

2. Agents that need changing facts and relationships

Use:

• Short-term: LangGraph state / Redis
• Long-term: Zep / Graphiti temporal graph

Example:

Bad memory:

User likes Python.

Better memory:

User
 ├── likes → Python
 │      valid_since: 2025
 │
 └── moved_from → JavaScript
        valid_since: 2026

This matters for:

• CRM agents
• Personal assistants
• Enterprise workflows
• Research agents

Zep's approach is built around temporal knowledge graphs, where relationships can change over time rather than being simple text retrieval.

---

3. Fully autonomous long-running agents

Use:

• Short-term: agent runtime memory
• Long-term: Letta

Letta treats memory more like an operating system:

• active context = RAM
• archival memory = disk
• agent decides what to keep or retrieve

Good for:

• coding agents
• autonomous researchers
• agents running for weeks/months

---

A practical memory model

I would separate memories into four types:

1. Working memory (seconds/minutes)

Examples:

• Current goal
• Current plan
• Tool results
• Temporary variables

Storage:

• LangGraph state
• Redis
• Postgres session table

---

2. Episodic memory (days/months)

"What happened?"

Examples:

2026-08-10:
User asked about Kubernetes migration.
Preferred AWS examples.

Storage:

• Vector search
• Embeddings
• Memory API

---

3. Semantic memory (months/years)

"What is true?"

Examples:

User prefers TypeScript.
Company uses AWS.
Project deadline is September.

Storage:

• Key-value store
• Knowledge graph

---

4. Procedural memory

"How should I behave?"

Examples:

Always provide code examples.
Use concise explanations.
Never recommend deprecated APIs.

Storage:

• Config/database
• System prompt fragments

---

My current recommendation by use case

Avoid this common mistake

Don't make "long-term memory" equal to:

all_chat_history → vector database → retrieve top K

That creates a noisy archive, not memory.

A good memory system needs:

1. Extraction — decide what matters
2. Consolidation — merge duplicates
3. Updating — handle changed facts
4. Forgetting — remove stale information
5. Retrieval — bring back only relevant memories

The strongest production designs treat memory as a lifecycle, not just storage.

If I were building a new agent today, I would start with LangGraph for short-term state + Mem0 for general long-term memory, and add a graph layer (Zep/Graphiti) only when relationships and changing facts become important.

If you're building an agent today, my default recommendation is:

Use LangGraph as the agent/runtime framework, with a checkpointer for short-term memory and a dedicated long-term memory store such as Mem0 or LangGraph Store.

This separation maps cleanly onto how memory actually behaves in production.

The architecture I'd use

                    ┌─────────────────────────┐
                    │       Agent / LLM        │
                    └────────────┬────────────┘
                                 │
                   ┌─────────────▼─────────────┐
                   │     Memory Manager        │
                   │                            │
                   │ retrieve → rank → inject  │
                   │ extract → validate → save │
                   └──────┬─────────────┬───────┘
                          │             │
             ┌────────────▼───┐   ┌────▼──────────────┐
             │ Short-term     │   │ Long-term         │
             │                │   │                   │
             │ Thread state   │   │ User preferences  │
             │ Recent turns   │   │ Facts             │
             │ Tool results   │   │ Past decisions    │
             │ Current plan   │   │ Learned behavior  │
             └───────┬────────┘   └────────┬──────────┘
                     │                     │
               Checkpointer          Memory Store
                (Postgres)        (Mem0 / LangGraph)

Short-term memory should answer: "What is happening right now?"

Long-term memory should answer: "What do I know about this user/task from before?"

LangGraph explicitly supports this split: checkpointers persist thread-scoped state, while stores persist cross-thread information such as user preferences and facts.

Which framework?

LangGraph is particularly attractive because you don't need a second framework just to solve short-term persistence. Its memory model already distinguishes thread state from durable cross-thread memory.

Mem0 is worth adding when you want a more purpose-built long-term memory layer. It handles memory extraction, deduplication/conflict resolution, and retrieval, with concepts such as session memory and persistent user memory.

Letta is compelling if you're building a genuinely stateful agent where the agent itself should continually inspect and modify its memory. Its MemFS system gives the agent a persistent, structured memory filesystem, including background "dreaming" for consolidating memories.

The important part: don't store everything

I'd use three layers:

1. Working memory — current conversation, plan, tool results, scratch state.
2. Episodic memory — important past interactions/events.
3. Semantic/profile memory — durable facts such as preferences, constraints, relationships, and recurring decisions.

Then have a memory policy:

Incoming message
      ↓
Retrieve relevant long-term memories
      ↓
Inject small relevant subset into working context
      ↓
Agent acts
      ↓
Determine what was actually worth remembering
      ↓
Write/update long-term memory asynchronously

That last step is crucial. Don't blindly save every conversation turn. LangChain's current guidance explicitly discusses background memory formation as a way to separate memory management from the latency-sensitive agent path.

My concrete recommendation

For a new production project, I'd start with:

LangGraph + PostgreSQL checkpointer + LangGraph Store

Then introduce Mem0 if you discover that sophisticated memory extraction/retrieval is becoming a significant engineering problem.

If your product's core differentiator is the agent remembering and evolving over months, I'd instead seriously consider:

Letta or LangGraph + Mem0.

The key architectural principle is more important than the specific vendor:

Keep working memory small and fast; keep long-term memory selective, searchable, scoped, and independently maintained.

That prevents the common mistake of treating an ever-growing conversation transcript as "memory." LangGraph's own documentation makes the same distinction, noting that long histories can increase cost and distract the model even when they technically fit in the context window.

If you tell me what kind of agent you're building (coding agent, personal assistant, customer support, autonomous workflow, etc.) and your stack (Python/TypeScript, OpenAI/Anthropic, Postgres/etc.), I can recommend a specific memory architecture and schema.

Integrating both short-term and long-term memory into an AI agent requires a tiered memory architecture . Short-term memory handles immediate task context and sliding conversation windows, while long-term memory captures persistent user preferences, episodic task outcomes, and semantic facts across sessions.

Instead of building this infrastructure from scratch, several purpose-built frameworks and architectural layers dominate production environments:

• Dedicated Memory Layers (Drop-in):
  • Mem0: Best for fast conversational personalization. It treats memory as a managed infrastructure layer, automatically extracting, updating, and compressing facts from interactions across sessions without redesigning your entire agent stack.
  • Zep / Graphiti: Best for temporal reasoning and complex, contradiction-heavy domains. Zep builds a temporal knowledge graph where time is a first-class dimension, tracking how facts and user preferences change or evolve.
  • Letta (formerly MemGPT): Best for autonomous, long-running agents. It takes inspiration from operating systems, giving the agent explicit, editable memory blocks and control over its own memory hierarchy (moving things between working memory and archival storage).
• Comprehensive Orchestration Frameworks:
  • LangGraph + LangMem: Best if you are already orchestrating your agent logic using LangGraph . LangGraph handles short-term state via built-in checkpointers (saving states at graph nodes), while its companion library LangMem manages background and hot-path long-term memory extraction and summarization.
  • CrewAI: Best for multi-agent workflows. It features a built-in three-tier memory structure utilizing semantic retrieval, short-term memory, and entity memory out of the box.
  • Cognee: Best for open-source, graph-vector hybrid memory control planes that run locally or self-hosted in privacy-regulated environments.

A standard production pattern splits the load cleanly:

1. Short-Term Layer (L1 Hot State): A low-latency in-memory cache or state store like Redis to manage immediate turns and task state.
2. Long-Term Semantic/Episodic Layer (L2/L3 Persistent Storage): A dedicated memory framework like Mem0 or Zep backed by vector search (e.g., Qdrant or Pinecone ) and relational/graph storage.

To help narrow down the best choice for your system, let me know:

• Are you looking for a managed API/cloud service or an open-source library to self-host?
• Is your agent single-user personalized (like a companion) or handling complex multi-step autonomous tasks?

If you're building a production agent that needs both conversation continuity and durable user memory, my default recommendation in 2026 is:

Use LangGraph as the orchestration/state layer, with short-term memory in its checkpointer and long-term memory in its Store. Add LangMem if you want automatic memory extraction/consolidation.

That architecture cleanly separates what the agent is currently doing from what the agent should remember permanently. LangGraph explicitly supports this two-layer model.

The architecture I'd use

                         ┌─────────────────────┐
                         │       Agent         │
                         │  reasoning + tools  │
                         └──────────┬──────────┘
                                    │
                 ┌──────────────────┴──────────────────┐
                 │                                     │
        SHORT-TERM MEMORY                      LONG-TERM MEMORY
        "What is happening?"                    "What do I know?"
                 │                                     │
        LangGraph Checkpointer                 LangGraph Store
                 │                                     │
          ┌──────▼──────┐                    ┌─────────▼─────────┐
          │ Thread state│                    │ User / org memory │
          │ messages    │                    │ facts/preferences │
          │ tool results│                    │ experiences       │
          │ current task│                    │ learned patterns  │
          └─────────────┘                    └───────────────────┘
                                                   │
                                            semantic retrieval
                                                   │
                                            ┌──────▼──────┐
                                            │ Relevant    │
                                            │ memories    │
                                            └─────────────┘

Short-term memory should be tied to a thread_id: conversation history, current task state, intermediate results, tool calls, etc. The checkpointer lets the agent resume a conversation or recover from interruptions.

Long-term memory should instead be associated with something like user_id, organization_id, or another namespace. It survives across conversations and can contain preferences, facts, prior experiences, and shared knowledge.

Don't just dump the entire conversation into long-term memory

This is the important architectural distinction.

I'd make long-term memory structured roughly like:

{
  "user_id": "123",
  "memory_type": "preference",
  "content": "Prefers concise technical explanations",
  "source": "conversation",
  "confidence": 0.94,
  "created_at": "...",
  "updated_at": "...",
  "last_confirmed": "...",
  "importance": 0.8
}

Then have the memory system decide:

1. Should this be remembered?
2. What type of memory is it?
3. Does it contradict an existing memory?
4. Should an existing memory be updated rather than creating another?
5. When should this memory be retrieved?
6. When should it expire or be forgotten?

That's substantially better than "embed every conversation and put it in a vector DB."

I'd divide long-term memory into 3 categories

1. Semantic memory — facts

"User works with Python."
"Company uses AWS."
"User's project uses PostgreSQL."

2. Episodic memory — experiences

"Last time we deployed this service, the migration failed because..."

3. Procedural memory — learned behavior

"When deploying this application, always run the integration tests first."

LangGraph's current memory guidance explicitly discusses semantic, episodic, and procedural memory as useful distinctions.

Where LangMem fits

If you don't want to build all the extraction/update logic yourself, LangMem is particularly interesting if you're already using LangGraph.

It provides memory-management tools plus a background memory manager that can extract, consolidate, and update knowledge over time, while integrating directly with LangGraph's Store.

So your stack becomes:

LangGraph
├── Checkpointer
│   └── Short-term / thread memory
│
├── Store
│   └── Long-term memory
│
└── LangMem
    ├── Extract memories
    ├── Search memories
    ├── Update/consolidate memories
    └── Background memory formation

For production, I'd use a persistent backend rather than the in-memory implementations used in examples; LangGraph documents PostgreSQL-backed checkpointers/stores for this purpose.

What about Mem0, Zep, or Letta?

They're worth considering if you don't want LangGraph's Store to be your memory implementation.

Current ecosystem comparisons similarly position Mem0 as a general-purpose option, Zep around temporal reasoning, Letta around autonomous/long-running agents, and LangMem around LangGraph-native systems.

My recommendation

If I were starting a new agent today:

Phase 1 — MVP

LangGraph
   +
Postgres
   +
Checkpointer
   +
Store

Phase 2 — intelligent memory

LangGraph
   +
LangMem
   +
Postgres

Phase 3 — sophisticated memory

Add specialized retrieval—semantic search, recency weighting, entity relationships, temporal validity, memory importance, and explicit memory lifecycle management—only when your agent actually needs it.

The biggest mistake I'd avoid is treating "long-term memory" as simply a vector database of old conversations. A good memory system is really a controlled knowledge lifecycle: extraction → storage → retrieval → updating → contradiction resolution → forgetting.

If you tell me what kind of agent you're building (coding agent, personal assistant, customer-support agent, research agent, etc.) and your stack (Python/TS, LangChain, OpenAI SDK, etc.), I can sketch the exact production architecture and database schema I'd use.

Choosing the best framework for short-term and long-term memory depends heavily on your existing agent orchestration stack and whether you need fast personalization or complex temporal/relational reasoning.

The industry has largely shifted away from primitive chat-history-buffering toward dedicated, tiered memory layers. The top choices categorized by use case include:

• Mem0 : Best for drop-in personalization and fast integration . It continuously extracts, updates, and compresses durable facts across sessions using a hybrid of vector search and entity linking. It has the widest ecosystem support and lowest integration friction for standard apps.
• LangGraph + LangMem : Best if your agent is already built on LangGraph . LangGraph checkpointers handle short-term conversational state seamlessly within a thread, while the cross-thread store and LangMem handle background memory formation and reflection outside the primary request loop.
• Zep (with Graphiti) : Best for temporal and contradiction-heavy domains . Zep builds a bi-temporal knowledge graph that tracks not just what an entity or user preference is, but when it became true and how it changes over time.
• Letta (formerly MemGPT) : Best for long-running autonomous agents . It mimics an operating system, giving the LLM explicit tool-based control to page data in and out between working memory and archival long-term storage.
• Cognee : Best for open-source graph-vector hybrid memory . It features a robust extract-cognify-load pipeline that turns raw data into structured knowledge graphs with zero initial infrastructure required locally.

To help narrow down the ideal framework for your project, let me know:

• What orchestration framework are you currently using to build your agent (e.g., LangGraph, CrewAI, custom loop)?
• Does your agent primarily need simple user preference recall or complex reasoning across changing data/time?