AI Agent Framework Comparison: How Each Handles Memory

An AI agent framework comparison that matters in production usually comes down to state: how each framework keeps conversation history, what it offers for long-term memory, and how easily you can plug in an external memory system. In October 2026, LangGraph and Letta give the most memory control, CrewAI and LlamaIndex the most built-in automation, and ADK, Microsoft Agent Framework and the OpenAI Agents SDK lean on sessions plus cloud or plug-in memory.

This page compares eight frameworks on memory, using each project’s docs and GitHub repo as of 8 October 2026. It isn’t a ranking of agent quality. For memory concepts, start with AI agent memory explained.

What is an AI agent framework?

An AI agent framework is a library that runs the loop around a language model: it calls the model, executes tools, routes between agents and keeps state. Memory is the part of that state that persists. Short-term memory is the history of one session or thread; long-term memory is what the agent keeps across sessions, such as user facts, summaries or learned procedures.

Every framework below handles short-term memory. They differ on three questions:

1. Persistence: does session history survive a restart, and on which databases?
2. Long-term memory: is there a built-in API for facts across sessions, and does it extract them for you?
3. Extensibility: can you plug in Mem0, Zep, a cloud memory service or your own store?

Agent framework memory comparison table

Hindsight entries are integrations listed in the Hindsight README; note that the CrewAI package pins crewai<1.10. Stars measure attention, not fit. Letta’s older letta repo has about 25,000 stars; current development is in letta-code.

LangGraph: checkpointers and the store

LangGraph’s memory docs split memory cleanly. Short-term memory is thread-scoped graph state, saved by a checkpointer so a thread can resume. Long-term memory lives in a store: JSON documents under a namespace tuple such as (user_id, "memories"), with put, get and search. Search can filter by content and, with an embedding index, rank by semantic similarity.

 1from langgraph.checkpoint.memory import InMemorySaver
 2from langgraph.store.memory import InMemoryStore
 3
 4checkpointer = InMemorySaver()   # thread history; use a DB-backed saver in production
 5store = InMemoryStore()          # cross-thread memory; use a DB-backed store in production
 6
 7namespace = ("user-123", "memories")
 8store.put(namespace, "diet", {"text": "User is vegetarian"})
 9print(store.search(namespace))
10
11# graph = builder.compile(checkpointer=checkpointer, store=store)

LangGraph leaves extraction to you, or to LangMem, LangChain’s memory library. The docs describe two write strategies: in the hot path (immediate, adds latency) or in the background (no latency, you decide when).

Best for: teams that want explicit control over every memory read and write.

CrewAI: one unified Memory class

CrewAI replaced its separate short-term, long-term, entity and external memory types with a single Memory class, per the CrewAI memory docs. Setting memory=True on a crew creates one. Storage defaults to LanceDB under ./.crewai/memory.

When you save without a scope or importance, an LLM infers them. When new content is at least 0.85 similar to an existing record, the LLM decides whether to keep, update, delete or insert. Recall ranks by a mix of semantic similarity, recency and importance, with a depth="shallow" mode that skips LLM calls.

1from crewai import Memory
2
3memory = Memory()
4memory.remember("We decided to use PostgreSQL for the user database.")
5for match in memory.recall("What database did we choose?"):
6    print(f"[{match.score:.2f}] {match.record.content}")

Memories sit in a path-like tree (/project/alpha), and you can scope or slice it. The default embedder is OpenAI text-embedding-3-large; stores built with older 1536-dimension embeddings can hit a dimension mismatch. More in CrewAI long-term memory.

Best for: multi-agent crews that want useful memory with little code.

OpenAI Agents SDK: sessions, plus sandbox memory

The OpenAI Agents SDK handles conversation history through Sessions. Built-ins include SQLiteSession, SQLAlchemySession, RedisSession, DaprSession, OpenAIConversationsSession (stored server-side by OpenAI), AdvancedSQLiteSession (branching and analytics) and an EncryptedSession wrapper with TTL, per the sessions docs.

1from agents import Agent, Runner, SQLiteSession
2
3agent = Agent(name="Assistant", instructions="Reply concisely.")
4session = SQLiteSession("user-123", "conversations.db")
5
6result = await Runner.run(agent, "My name is Ana.", session=session)
7result = await Runner.run(agent, "What's my name?", session=session)

Sessions don’t extract facts across conversations. For sandbox agents, the SDK has a separate Memory capability: after a sandbox session closes, a model distills runs into memories/MEMORY.md and a short memory_summary.md that’s injected at the start of the next run. It needs the Shell capability to read and Filesystem for live updates. See OpenAI Agents SDK memory for patterns.

Best for: OpenAI-centric apps that want simple, swappable session storage.

Microsoft Agent Framework: sessions and context providers

Microsoft Agent Framework (MAF) is the successor to AutoGen, whose README now says it is in maintenance mode and points new users to MAF 1.0, the production-ready release.

Memory runs through two extension points. History providers load and save the message transcript for an AgentSession; InMemoryHistoryProvider is the default. Context providers run before and after each call to add instructions, messages or tools and to store what they learn. FileMemoryProvider gives the model file_memory_* tools, with a scope (for example a user ID) to share memory across sessions.

The listed context provider integrations include Mem0 (Python), Redis, Neo4j, Azure Cosmos DB and Microsoft Foundry memory. That last one connects to Azure AI Foundry long-term memory. One gap: the vector-based ChatHistoryMemoryProvider is C# only for now.

Best for: .NET and Azure shops, and AutoGen users who need a supported path.

Google ADK: state prefixes and memory services

ADK separates session state from memory. State keys are scoped by prefix: none (this session), user: (all of a user’s sessions in the app), app: (all users) and temp: (this invocation only). Persistence depends on the session service.

Long-term memory goes through a MemoryService: InMemoryMemoryService (prototyping, keyword match), VertexAiRagMemoryService (vector search) or VertexAiMemoryBankService, which uses Google’s managed Memory Bank to extract and consolidate facts per user. Agents read memory with PreloadMemoryTool (every turn) or LoadMemoryTool (when the model decides). The Vertex AI Agent Engine Memory Bank page covers the managed side and pricing.

Best for: Gemini and Google Cloud deployments.

Letta, LlamaIndex and Pydantic AI

Letta (formerly MemGPT) is the only framework here designed around memory first. The agent edits its own memory, now stored as Markdown files in MemFS, a git-backed memory filesystem; root files load into every prompt, deeper ones on demand. Archival memory holds vector-searchable passages, and background “dreaming” subagents consolidate lessons. The current product is Letta Code, with a TypeScript SDK; Letta’s docs mark the Python client as deprecated.

LlamaIndex has a Memory class with a token limit (default 30,000) split between chat history (70% by default) and long-term memory blocks: StaticMemoryBlock, FactExtractionMemoryBlock and VectorMemoryBlock. History beyond the ratio is flushed into the blocks. Storage defaults to in-memory SQLite, or any async SQL database.

Pydantic AI core doesn’t store history. You pass message_history= to each run and serialize with ModelMessagesTypeAdapter. Its Harness add-on provides step persistence, conversation search and a Memory capability for Markdown notes.

How to pick, and when to add a memory layer

1. Pick the framework for orchestration first, then check its memory story. Changing frameworks to get memory is rarely worth it.
2. Use built-in session storage for history, on a real database, from day one.
3. Decide whether you need extraction. If users expect “remember my preferences,” you need something that turns chats into facts: CrewAI’s Memory, LlamaIndex fact blocks, LangMem, a cloud memory service or an external layer.
4. Add an external memory layer when memory must be shared across frameworks or apps, or when you need features like temporal facts or learning from experience. Mem0, Zep, Cognee, Letta and Hindsight all work as tools or MCP servers in any framework. Hindsight has the widest framework coverage of these in its own README (LangGraph, LlamaIndex, CrewAI, Pydantic AI, OpenAI Agents SDK, ADK, Microsoft Agent Framework and more), ships graph, temporal recall and consolidation in its MIT server, and leads Mem0 on the long-history BEAM tests (73.9 vs 64.1 at 1M tokens, vendor-reported). Its cost: every write calls an LLM, and it returns more context per retrieval than Mem0 unless you lower max_tokens. Best AI memory framework compares them by use case.
5. Test recall on your own data before you ship.