The AI Agent Memory Catalog

Source: github.com/langchain-ai/langgraph (43k+ stars, MIT)

Intent

Model agent execution as a graph of nodes operating on a typed state object, with the framework managing state persistence, replay, and human-in-the-loop interrupts.

Motivating Problem

Covered in detail in Volume 9, LangGraph (multi-agent). The fabric-memory-relevant point: LangGraph’s state object is the canonical short-term working memory of an agent run, and its checkpointers (in-memory, SQLite, Postgres, Redis, and the managed LangSmith Deployment) are how that working memory survives across process restarts and supports time-travel debugging.

How It Works

The typed state object --- a TypedDict or Pydantic model --- flows through nodes; each node returns updates to the state; the framework merges updates and persists snapshots at every transition. Compiling with compile(checkpointer=…) and invoking with config={“configurable”: {“thread_id”: ”…”}} ties a run to a persistent thread, and the checkpointer stores every snapshot keyed by thread_id and step number.

For memory purposes, the most important property is that the entire state of a long-running agent is queryable and restorable at any past point. Time-travel debugging --- “start the agent over from this snapshot but with a different decision at step seven” --- is a first-class operation. Production debugging benefits enormously.

When to Use It

Stateful agent runs where the in-progress state is non-trivial and needs to survive failures. Anywhere the team is already on LangGraph. Cases where time-travel debugging is operationally valuable. See Volume 9, LangGraph (multi-agent), for fuller treatment.

Alternatives --- CrewAI Flows, LlamaIndex Workflows, Microsoft Agent Framework workflows. The state-management story differs in detail but the operational shape is similar across the four. Checkpoints are per thread; for memory that carries across threads, see the LangGraph long-term memory Store and LangMem (Section C).

Sources

• docs.langchain.com/oss/python/langgraph/persistence

Source: redis.io (Redis 8+: RSALv2 / SSPLv1 / AGPLv3; Valkey is the BSD-3 fork; via RedisChatMessageHistory in LangChain et al.)

Intent

Persist conversation threads in Redis for sub-millisecond reads and writes, with TTL-based expiration and the option to back it with disk-persistent Redis variants for durability.

Motivating Problem

For agents that handle many concurrent conversations --- chatbots, customer support, multi-user assistants --- the conversation thread itself becomes a hot path. Loading the last fifty messages from a relational store on every turn produces visible latency; loading them from Redis takes a millisecond. Most agent stacks already have Redis running for caching; adding a chat-history layer on top is one of the smallest-friction memory investments available.

How It Works

Each conversation gets a Redis key (typically session:user_id or chat:thread_id) backed by a Redis list of messages. Push on the back for new messages; lrange to read the last N. TTL on the key handles session expiration. Wrappers like LangChain’s RedisChatMessageHistory or the OpenAI Conversations API (used with the Responses API) abstract the operations behind a clean interface.

For durability, Redis AOF (append-only file) and RDB snapshots provide acceptable durability for chat history that’s not the system of record. For higher-durability needs, the same pattern works against Postgres or DynamoDB at the cost of higher per-operation latency.

When to Use It

Any agent application with concurrent conversations and per-turn latency budgets. The default for short-term conversation persistence; almost always worth the modest operational cost.

Alternatives --- in-process dictionaries when the application is single-process and conversations don’t need to survive restarts (rare in production). Postgres-backed history when Redis isn’t already in the stack. The LangGraph or framework-provided persistence layer when the framework abstracts it.

Sources

• redis.io

• docs.langchain.com/oss/python/integrations/providers/redis

Example artifacts

Code.

from langchain_redis import RedisChatMessageHistory

history = RedisChatMessageHistory(

session_id="user_42",

url="redis://localhost:6379/0",

ttl=3600 * 24 * 7, # one week

)

history.add_user_message("What did we discuss last time?")

history.add_ai_message("You asked about kitchen renovation costs.")

for msg in history.messages:

print(msg.type, msg.content)

Source: github.com/chroma-core/chroma (Apache-2; Python/TypeScript SDKs; embedded or client/server)

Intent

Provide a vector database that runs in-process inside a Python application for fast prototyping, with a path to a client/server deployment when scale demands it.

Motivating Problem

For agent prototypes and small-scale memory deployments, the operational overhead of running a separate vector database is real and unnecessary. Chroma’s answer is to embed the database directly in the Python (or TypeScript) application: a few lines of import-and-call, persistent storage in a local directory, no separate process to manage. The same API works against a client/server deployment when the prototype graduates to production.

How It Works

Install chromadb, instantiate a PersistentClient pointed at a directory, create or get a collection, and add documents with their embeddings (computed by Chroma using a default embedding function or supplied by the caller). Query is a single .query() call returning the top-k nearest neighbors with their documents and metadata. The client/server mode runs the same API surface against a remote Chroma server.

Chroma’s positioning is explicitly developer-friendly. The documentation, the API surface, and the default behaviors prioritize “it just works in five lines” over operational sophistication. The trade-off is that Chroma at scale (millions of vectors, dozens of concurrent users) is operationally less comfortable than Qdrant or Pinecone; the prototype path is excellent.

When to Use It

Prototypes, demos, and small-to-medium production deployments where the in-process embedding is operationally simpler. Agent memory layers (Mem0, Letta) that abstract over Chroma in their default configuration. Anywhere the team wants the simplest possible vector-store onboarding.

Alternatives --- Qdrant when production performance and feature surface matter. Pinecone when fully-managed hosting is preferred. pgvector when Postgres is already in the stack.

Sources

• github.com/chroma-core/chroma

• docs.trychroma.com

Example artifacts

Setup.

pip install chromadb

Code.

import chromadb

client = chromadb.PersistentClient(path="./memory_db")

coll = client.get_or_create_collection(name="alice_memories")

coll.add(

documents=["Alice prefers spicy food", "Alice is allergic to
peanuts"],

metadatas=[{"category": "preference"}, {"category":
"allergy"}],

ids=["mem_001", "mem_002"],

)

results = coll.query(

query_texts=["What food restrictions does Alice have?"],

n_results=3,

)

print(results["documents"])

Source: github.com/qdrant/qdrant (Apache-2; Rust; client SDKs in Python/TS/Rust/Go/Java)

Intent

Provide a production-grade vector database written in Rust, with distributed deployment, rich payload filtering, hybrid search, and the operational maturity to back agent memory at scale.

Motivating Problem

For agent memory at production scale --- millions of vectors, dozens of concurrent users, sub-100ms p99 retrieval latency --- the requirements outgrow Chroma’s in-process mode and the cost profile of Pinecone’s pure SaaS becomes painful. Qdrant occupies the production-grade-open-source position: written in Rust for performance, distributed by design, with the payload-filtering and hybrid-search features that production memory needs.

How It Works

Collections hold points; each point is a vector plus a JSON payload. The payload supports rich filtering (range queries, geo, full-text, nested fields), which is essential for agent memory because retrieval is rarely pure vector --- it’s usually “find similar memories for user_id=alice in the last 30 days with importance > 0.5,” where the filter dramatically reduces the search space before the vector comparison runs.

Hybrid search combines vector similarity with sparse vectors (BM25-style keyword scoring) for retrieval that handles both semantic similarity and exact-term matches. Qdrant’s sparse-vector support is first-class; the Mem0 documentation calls out Qdrant explicitly for the production hosting path.

Operational: Qdrant runs in single-node mode for development and in a distributed cluster for production. Qdrant Cloud is the hosted offering; the open-source binary is the self-hosted option. Performance benchmarks consistently place Qdrant at or near the top of the open-source vector database category.

When to Use It

Production agent memory deployments. Cases requiring rich payload filtering (per-user isolation, time-range queries, importance thresholds). Hybrid search workloads. Any scale beyond “small prototype.”

Alternatives --- Pinecone for fully-managed hosting; pgvector when Postgres is preferred; Chroma for prototypes; Weaviate for multimodal-or-graph-heavy workloads.

Sources

• github.com/qdrant/qdrant

• qdrant.tech/documentation/concepts/search/

Example artifacts

Setup.

# Self-hosted:

docker run -p 6333:6333 -p 6334:6334 \

-v \$(pwd)/qdrant_storage:/qdrant/storage \

qdrant/qdrant

# Python client:

pip install qdrant-client

Code.

from qdrant_client import QdrantClient

from qdrant_client.models import PointStruct, Filter, FieldCondition,
MatchValue

client = QdrantClient(url="http://localhost:6333")

client.create_collection(

collection_name="agent_memories",

vectors_config={"size": 1536, "distance": "Cosine"},

)

# Write with payload metadata for filtering

client.upsert(

collection_name="agent_memories",

points=[PointStruct(

id=1,

vector=embedding_of("Alice prefers spicy food"),

payload={"user_id": "alice", "category": "preference",
"timestamp": 1716000000},

)],

)

# Per-user filtered query (Query API; search() is deprecated)

hits = client.query_points(

collection_name="agent_memories",

query=embedding_of("food preferences"),

query_filter=Filter(must=[

FieldCondition(key="user_id", match=MatchValue(value="alice")),

]),

limit=5,

).points

Source: pinecone.io (SaaS; closed-source; Python/TypeScript clients)

Intent

Provide vector search as a pure SaaS, with no operational responsibility for the deployer: API key in, vectors in, queries out, with serverless scaling and global availability.

Motivating Problem

For teams that want production-grade vector search without operating any infrastructure, Pinecone has been the incumbent answer since 2021. Pure SaaS, no servers to run, pay-per-vector-stored-and-query. The trade-off is dependency on a single vendor and the cost profile, which can be significant at scale; the upside is zero operational overhead and the maturity of a several-years-old hosted product.

How It Works

Create an index via the dashboard or API; choose a dimension matching your embedding model; upsert vectors with metadata; query by vector or by metadata filter. The serverless model (introduced 2024) eliminates the older pod-based provisioning; usage-based pricing scales with storage and read units. Hybrid search and metadata filtering are first-class.

Pinecone’s positioning leans heavily into the managed-service angle: SOC 2, HIPAA, regional deployments, SLA-backed. For agent memory in regulated industries (healthcare, financial services), this is the path of least resistance for the security questionnaire alone. Pinecone also runs its own MCP server, so an agent can query an index as a tool.

When to Use It

Teams that explicitly don’t want to operate vector-store infrastructure. Regulated industries where the managed compliance posture is valuable. Pilots that may scale fast and want the operating burden to scale with them.

Alternatives --- Qdrant Cloud for managed open-source. AWS OpenSearch with k-NN for AWS-native deployments. The self-hosted-Qdrant-or-Chroma path when cost-control matters and the team has the operational maturity.

Sources

• pinecone.io

• docs.pinecone.io

Source: github.com/weaviate/weaviate (BSD-3-Clause; Go; Python/JS/Go clients)

Intent

Provide vector search with first-class support for multi-vector objects, multimodal data (text + image + audio embeddings on the same object), and graph-like relationships between objects.

Motivating Problem

For agent memory that goes beyond text --- a memory might include the screenshot the user shared, the audio clip from a voice note, the structured event data from a calendar --- single-modality vector stores create awkward modeling problems. Weaviate’s answer is multi-vector objects (one record carries multiple embeddings across modalities) and explicit cross-references between objects, making it natural to model both rich memories and the relationships between them.

How It Works

Objects are stored in classes (collections). Each class has a schema with properties and vector configurations; multiple vectors per object are supported (named-vector mode). Cross-references let one object reference another, producing a graph structure that’s queryable. Modules add specialized capabilities: text2vec-openai for embedding, multi2vec-clip for image+text, ref2vec-centroid for derived embeddings.

Compared with Qdrant or Pinecone, Weaviate is genuinely different in shape: less a pure vector-search engine and more a vector-aware object database with graph semantics. The trade-off is feature breadth versus operational simplicity --- Weaviate is more capable but harder to operate well.

When to Use It

Multimodal agent memory (screenshots, audio, structured data alongside text). Workloads with rich object-to-object relationships that benefit from a graph model. Teams that prefer GraphQL-style query semantics.

Alternatives --- Qdrant for pure vector search at scale; Pinecone for managed; a dedicated graph database (Neo4j) when the graph is the primary structure; pgvector when Postgres is the existing stack.

Sources

• github.com/weaviate/weaviate

Source: github.com/lancedb/lancedb (Apache-2; Rust core; Python, Node.js, Rust and REST APIs)

Intent

Provide a vector store that runs inside the application process and keeps its data as files in the Lance columnar format, on local disk or object storage, with no server to operate.

Motivating Problem

Chroma covers the embedded prototype case, but agent memory often outgrows “a directory on one laptop” without justifying a database cluster: the store should sit in a bucket, be versioned, and hold more than text. LanceDB keeps the embedded model (import a library, point it at a path) while storing data in a columnar format built for large and multimodal datasets. CrewAI chose it as the default backend for its unified memory, which makes it the store many crews use without configuring one.

How It Works

The library opens a database at a path (a local directory or an object-store location) and stores tables as Lance files. Each table holds vectors alongside metadata and multimodal data (text, images, video, point clouds). Queries combine vector similarity search, full-text search and SQL-style filtering. Tables are versioned automatically, so earlier states of a memory store can be inspected or restored without extra infrastructure. LanceDB Cloud and Enterprise offer the same model as a managed service.

For agent memory, the practical properties are the zero-ops start, per-user filtering through metadata columns, and the ability to move the files from a laptop to object storage without changing the API. CrewAI keeps its memory under ./.crewai/memory in LanceDB unless told otherwise.

When to Use It

Embedded agent memory that should persist to object storage. Multimodal memory where images or audio sit next to their embeddings. CrewAI deployments (it is already the default). Teams that want versioned memory snapshots.

Alternatives --- Chroma for the simplest Python prototype path. Qdrant or Pinecone when many concurrent writers need a server. pgvector when Postgres is already in the stack.

Sources

• github.com/lancedb/lancedb

• docs.lancedb.com

• docs.crewai.com/en/concepts/memory

Source: github.com/mem0ai/mem0 (67k+ stars, Apache-2; Python + TypeScript)

Intent

Provide a memory layer that integrates with any agent framework, automatically extracts and stores user-relevant facts, retrieves them with hybrid scoring, and exposes a uniform add()/search() API.

Motivating Problem

Production agent applications that don’t want to build the memory layer themselves --- the fact-extraction logic, the dedup heuristics, the update rules, the multi-user isolation, the vector-store abstraction --- need a memory product to drop in. Mem0 positions itself as that product, with by far the broadest framework-integration coverage (21 frameworks as of early 2026 including LangChain, CrewAI, AutoGen, Mastra, the OpenAI Agents SDK) and a retrieval path that combines several scoring signals.

How It Works

Install mem0ai; instantiate a Memory() with optional configuration for the vector store, LLM, and embedder; call m.add(text, user_id=…) to store an observation; call m.search(query, filters={“user_id”: …}) to retrieve relevant memories. On add(), Mem0 makes one LLM call to extract facts from the observation and stores them as new memories (the current open-source algorithm is ADD-only, with no UPDATE or DELETE events). Retrieval uses hybrid scoring: semantic similarity, BM25 keyword match, and entity overlap, where entities extracted from each memory boost results that share entities with the query.

The multi-signal retrieval is the architectural distinctiveness. Pure vector similarity misses exact names and IDs; keyword match misses paraphrase; entity overlap ties a question about Alice to memories that mention Alice. Qdrant is the usual production vector backend. Graph memory, for relationship queries such as “what does Alice’s sister prefer”, is a Mem0 Platform (hosted) feature; the open-source library no longer has a graph store.

Operational: self-hostable with docker compose up; managed via app.mem0.ai with free-tier API keys; agents can mint their own keys (mem0 init —agent), with the human owner claiming the account later. The CLI surface is unusual in being explicitly designed for AI coding agents to interact with directly, and an MCP server makes Mem0 available to any MCP-compatible agent without SDK code. The memory-benchmarks repo (github.com/mem0ai/memory-benchmarks) is the open-source harness Mem0 uses to run LoCoMo, LongMemEval and BEAM (Section G) against its own Cloud and OSS backends; it has no adapters for other memory systems.

When to Use It

Production agent applications that need a memory layer without building one. Multi-framework deployments where the memory layer should outlive any single framework choice. Cases where the hosted Platform’s graph memory adds real value (multi-user systems, social-context tasks). Mem0 ships with the broadest integration surface and the most production reference deployments.

Alternatives --- Letta for agent-managed memory with a research-grounded design; Zep for temporal knowledge-graph memory. Roll-your-own on top of Qdrant or Chroma when the memory layer needs to be fully under team control. The decision is mostly about how much of the lifecycle you want to own versus delegate.

Sources

• github.com/mem0ai/mem0

• mem0.ai/blog/state-of-ai-agent-memory-2026

• github.com/mem0ai/memory-benchmarks

Example

A customer-support agent that handles thousands of users across many sessions. Each user-message arrival triggers m.add() with user_id=alice; the fact-extractor distills any preferences, account details, or task progress; the next time Alice writes in (possibly weeks later), m.search() retrieves the relevant prior memories. On the hosted Platform, graph memory tracks relationships (Alice’s account is associated with her company, whose support tier dictates SLA), making queries like “what’s Alice’s support tier” resolvable through the graph rather than requiring the SLA to be repeated in every conversation.

Example artifacts

Setup.

pip install mem0ai

# or for the CLI:

npm install -g \@mem0/cli

# Self-hosted server:

cd server && make bootstrap # one-command setup, admin wizard
included

Code.

import os

from mem0 import Memory

os.environ["OPENAI_API_KEY"] = "sk-..."

# Default config: in-memory store; production should configure
Qdrant.

m = Memory()

# Write

result = m.add(

"I am working on improving my tennis skills. Suggest some online
courses.",

user_id="alice",

metadata={"category": "hobbies"},

)

# Read (entity IDs go inside filters)

memories = m.search(

"What hobbies is Alice working on?",

filters={"user_id": "alice"},

)

for mem in memories["results"]:

    print(mem["memory"], mem["score"])

Source: github.com/letta-ai/letta (Apache-2; 25k+ stars)

Intent

Make memory something the agent manages itself: it decides what to keep in context, what to write down, and what to look up, starting from MemGPT’s OS-style memory hierarchy and now implemented as memory files the agent edits.

Motivating Problem

The original MemGPT research paper (2023) argued that LLM context windows are like RAM --- fast but limited --- and that long-term agent memory should be structured like a complete OS memory hierarchy, with explicit paging between tiers and explicit functions the agent can call to manage its own memory. Letta is the productization of that research: an agent runtime where memory management is a first-class agent capability rather than a hidden retrieval step.

How It Works

The original MemGPT design gave the agent three tiers: a main context (the LLM context window, with a small memory block the agent could rewrite), recall memory (the full conversation history, searchable), and archival memory (arbitrary stored content), managed through tool calls such as core_memory_replace, archival_memory_insert and archival_memory_search.

Current Letta keeps the idea that the agent manages its own memory and changes the storage. Memory is a set of labelled blocks stored as Markdown files in a git repository owned by the agent (MemFS). Files under system/ are compiled into the system prompt every turn; everything else stays out of context, and the agent sees the file tree and reads what it needs. Edits become memory once they are committed. Shared memory repositories give several agents access to the same files. “Dreaming” runs background subagents that review recent conversations, consolidate lessons, and update memory without interrupting active work, triggered after a number of steps or on context compaction.

The architectural distinctiveness is that memory management is exposed to the agent as a tool rather than hidden behind a black-box retrieval layer. The agent decides what to remember, what to forget, what to look up. The trade-off is that agent prompts are more complex (the agent has to learn the memory tools) but the resulting memory behavior is more interpretable and controllable.

Letta the company (founded by the MemGPT authors) productizes the research as a hosted platform with agent persistence, multi-user support, and observability. The self-hosted open-source version (the letta-ai/letta repo) provides the same architecture without the hosted infrastructure; shared repositories are hosted by Letta, so self-hosted deployments share memory by pointing agents at their own git remote. Letta also ships the Letta Harness (formerly Letta Code).

When to Use It

Agents where memory management is part of the agent’s reasoning, not infrastructure underneath. Research applications where the OS-memory metaphor is a productive frame. Cases where you want the agent to make explicit decisions about what to remember and what to forget.

Alternatives --- Mem0 for the simpler add()/search() interface where memory management is opaque to the agent. Zep for temporal knowledge-graph memory. The choice is essentially architectural philosophy: should the agent be aware of its memory or not?

Sources

• github.com/letta-ai/letta

• docs.letta.com/agent-sdk/memory

• research.memgpt.ai (Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023)

Source: getzep.com (managed service or bring-your-own-cloud; SDKs for Python, TypeScript and Go); open-source engine: github.com/getzep/graphiti (Apache-2)

Intent

Serve as a managed long-term memory and context store for AI assistant apps: build a temporal knowledge graph from conversations and business data, and assemble the right context from it for each turn.

Motivating Problem

For conversation-heavy AI assistants --- customer support bots, productivity copilots, AI tutors --- the conversation thread itself is the primary memory substrate, and the dominant operational concern is what to summarize and what to keep verbatim. Zep’s answer is to turn the conversation into structure: Zep builds a temporal knowledge graph (Graphiti) from conversations and business data and assembles context from it, so facts that changed are tracked rather than summarized away.

How It Works

An agent writes user messages, AI responses and business data to Zep via the SDK. Zep 2.0 introduced Graphiti, a temporal knowledge graph that captures entities, relationships and facts from that data, each fact with a validity window. Retrieval combines semantic, keyword and graph search, and Zep assembles the results into a context block sized for the application’s budget.

Graphiti is the open-source core (Section F); Zep adds the managed layer on top: governed, low-latency retrieval for many graphs, running on Zep’s proprietary Context Graph Engine. The older github.com/getzep/zep repository now holds examples and integrations for the managed service, not a self-hostable server.

When to Use It

Conversation-heavy AI assistants where session continuity over days or weeks is the primary memory need. Workloads where facts change and the history of a fact matters. Cases where temporal knowledge graphs add value (entity resolution, relationship queries) and a managed service is preferred over running Graphiti.

Alternatives --- Graphiti self-hosted (Section F) for the same engine without the managed service. Mem0 for the broader fact-extraction positioning. Letta for agent-managed memory. Roll-your-own when the conversation patterns require custom summarization policies.

Sources

• getzep.com

• github.com/getzep/graphiti

• help.getzep.com

Source: docs.langchain.com/oss/python/langgraph/add-memory ; github.com/langchain-ai/langmem (MIT)

Intent

Give LangGraph agents memory that outlives a single thread: a store keyed by namespace (typically the user), with optional semantic search, plus LangMem tools that let the agent record and search memories and a background manager that extracts and consolidates them.

Motivating Problem

LangGraph checkpointers (Section A) persist state per thread_id, so a new conversation starts empty. Facts about a user that should carry across conversations need storage keyed by the user, not the thread. Teams already on LangGraph want that without adding a separate memory product and a second set of credentials.

How It Works

The graph is compiled with a store as well as a checkpointer: compile(checkpointer=…, store=…). InMemoryStore serves development; PostgresStore and a Redis store serve production. Inside a node, the runtime exposes the store: memories are written with put under a namespace tuple such as (user_id, “memories”) and read with search(namespace, query=…, limit=3). Configuring the store with an embedding model and dimension turns search into semantic search.

LangMem builds on the store. create_manage_memory_tool and create_search_memory_tool give the agent tools to record and look up memories during a conversation (the hot path). A background memory manager extracts, consolidates and updates memories after the fact, off the hot path. LangMem’s functional primitives also work with other storage, but the LangGraph store integration is the default.

When to Use It

LangGraph agents that need per-user memory across threads. Teams that want long-term memory in the same Postgres or Redis they already use for checkpoints. Cases where the agent itself should decide what to remember, with tools rather than an opaque layer.

Alternatives --- Mem0 or Zep when memory should be independent of the orchestration framework. Letta for agent-managed memory files. CrewAI’s built-in memory (Section D) for crews.

Sources

• docs.langchain.com/oss/python/langgraph/add-memory

• github.com/langchain-ai/langmem

Example artifacts

Code.

from langgraph.prebuilt import create_react_agent
from langgraph.store.memory import InMemoryStore
from langmem import (
    create_manage_memory_tool,
    create_search_memory_tool,
)

# Production: PostgresStore or a Redis store
store = InMemoryStore(index={
    "dims": 1536,
    "embed": "openai:text-embedding-3-small",
})

agent = create_react_agent(
    "anthropic:claude-haiku-4-5",
    tools=[
        create_manage_memory_tool(namespace=("memories",)),
        create_search_memory_tool(namespace=("memories",)),
    ],
    store=store,
)

Source: docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html ; docs.cloud.google.com/agent-builder (Agent Platform Memory Bank)

Intent

Buy agent memory as a cloud service: the provider stores session events, runs LLM extraction to turn them into long-term memories, and serves them back, under the same IAM, encryption and compliance controls as the rest of the account.

Motivating Problem

Teams building on AWS or Google Cloud often cannot send conversation data to a third-party memory vendor, and do not want to run Mem0 or Graphiti themselves. The hyperscalers now offer the memory layer as part of their agent platforms, so memory inherits the account’s access control, data residency and compliance posture.

How It Works

Amazon Bedrock AgentCore Memory has two types that work together. Short-term memory captures turn-by-turn interactions within a session. Long-term memory extracts and stores insights across sessions: user preferences, important facts and session summaries. Long-term extraction is driven by strategies attached to the memory resource. Built-in strategies handle extraction and consolidation with predefined algorithms; built-in overrides let a team change the prompts and use Bedrock models in its own account; self-managed strategies hand the whole pipeline (schemas, namespaces, models) to the team. Without a strategy, no long-term records are extracted.

Google Cloud’s Agent Platform pairs Sessions (state within a single agent interaction) with Memory Bank (persistent memory across sessions). Memory Bank generates memories from ingested events with generative models, supports memory profiles and uploaded memories, keeps memory revisions that can be inspected, and controls access through IAM Conditions. It supports VPC Service Controls, customer-managed encryption keys, data residency at rest and HIPAA. The Agent Development Kit (ADK) has a Memory Bank quickstart.

When to Use It

Agents deployed on AWS (AgentCore) or Google Cloud (Agent Platform) where memory should stay inside the cloud account. Regulated workloads that need the provider’s compliance coverage. Teams that want managed extraction without operating a memory layer.

Alternatives --- Mem0 or Zep for a cloud-neutral managed memory layer. The LangGraph Store or Graphiti when the team wants to own the pipeline. Volume 5 (AWS Bedrock AgentCore) covers AgentCore as a platform beyond memory.

Sources

• docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html

• docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory-strategies.html

• docs.cloud.google.com/agent-builder/agent-engine/memory-bank/overview

Source: github.com/crewAIInc/crewAI (Python, MIT)

Intent

Provide built-in, opinionated memory for multi-agent crews: a single unified Memory class shared by the crew, with hierarchical scopes, LLM-driven consolidation of similar records, and recall ranked by similarity, recency and importance.

Motivating Problem

For multi-agent crews working on shared tasks, the group-chat pattern’s token-cost scaling becomes prohibitive past three or four agents. CrewAI’s answer is a shared memory that agents access by API rather than by reading the conversation. Earlier releases split it into short-term, long-term, entity and external memory types; the current release replaces them with one Memory class.

How It Works

Memory is enabled per crew with memory=True (or a configured Memory instance); all agents in the crew share the crew’s memory unless an agent has its own. After each task, the crew extracts discrete facts from the task output and stores them; before each task, the agent recalls relevant context. On save, an LLM infers the record’s scope (a path such as /project/alpha), categories and importance; a new record that is very similar to an existing one (similarity above 0.85 by default) goes to the LLM, which decides how to consolidate the two. Recall ranks by a composite of semantic similarity, recency and importance, with tunable recency weight and half-life. Storage is LanceDB under ./.crewai/memory by default, with OpenAI text-embedding-3-large embeddings unless another embedder is configured.

Agents access memory through the framework rather than through prompt context: the framework injects relevant memory into the agent’s prompt before each LLM call. This keeps individual agent contexts small while preserving access to shared state. The trade-off is that the framework’s injection logic has to choose what’s relevant --- done well, it works; done poorly, agents end up missing context they should have had.

When to Use It

Multi-agent crews larger than the group-chat sweet spot (four or more agents). Tasks where a shared, scoped memory fits naturally. Teams already using CrewAI for agent orchestration.

Alternatives --- group-chat orchestration (Microsoft Agent Framework, Volume 5) for smaller, conversation-shaped collaborations. External-DB shared state (Section E) when memory needs to span beyond a single crew or survive crew restarts.

Sources

• github.com/crewAIInc/crewAI

• docs.crewai.com/en/concepts/memory

Source: supabase.com (managed and self-hostable; Apache-2 components)

Intent

Provide Postgres plus pgvector plus auth plus real-time subscriptions as a coherent backend, suitable as the unified state-and-memory store for AI agent applications.

Motivating Problem

Most AI agent applications need a relational database for structured state (users, projects, tasks, audit logs), a vector store for memory, an auth system for users, and often a real-time push mechanism for UI updates. Building this stack from components is a real amount of work for what most teams correctly recognize as undifferentiated heavy lifting. Supabase packages all four as a single product, with Postgres at the center, and explicit AI/agent positioning around the pgvector integration.

How It Works

Supabase projects run a Postgres instance that ships pgvector as an available extension, enabled with one click in the dashboard or with create extension vector. The dashboard exposes the database, the auth users, the storage buckets, and the real-time channels through one UI. SDKs (JS, Python, Dart) provide typed access. Vector columns are first-class --- a table can have a normal id column, a normal text column, a vector(1536) column, and a normal jsonb metadata column, all in the same row, queryable through the same client.

For agent state plus memory, the natural pattern is: a sessions table for live agent state (status, current task, in-flight work), a memories table for long-term memory (id, user_id, content, embedding vector(1536), metadata jsonb, created_at, importance), and indexes on user_id and on the vector column. Queries combine SQL filtering (WHERE user_id = ? AND created_at > now() - interval ‘30 days’) with vector similarity (ORDER BY embedding <=> $1 LIMIT 10, cosine distance), all in one query.

Operational: Supabase is hosted (with a generous free tier) and also self-hostable via docker compose. Row-Level Security policies in Postgres handle per-user isolation, which matters acutely for agent memory --- one user’s memories should not surface in another’s retrieval. RLS lets the team enforce this at the database layer rather than at the application layer.

When to Use It

AI agent applications where the relational layer is real (projects, users, tasks, audit trails) and adding a memory layer should not mean adding a second database. Multi-tenant applications where Postgres RLS for per-tenant isolation is a feature. Teams that prefer SaaS over self-hosting for operational efficiency.

Alternatives --- raw Postgres plus pgvector (next entry) when the auth and real-time features aren’t needed. Dedicated vector stores (Section B) when vector volume exceeds what pgvector handles comfortably. Firebase or similar when the relational angle is light and the document model fits better.

Sources

• supabase.com

• github.com/supabase/supabase

Example artifacts

Schema / config.

-- Schema for unified state + memory

create extension if not exists vector;

create table sessions (

id uuid primary key default gen_random_uuid(),

user_id uuid references auth.users,

status text not null,

current_task text,

created_at timestamptz default now(),

updated_at timestamptz default now()

);

create table memories (

id uuid primary key default gen_random_uuid(),

user_id uuid references auth.users,

content text not null,

embedding vector(1536),

metadata jsonb,

importance real default 0.5,

created_at timestamptz default now()

);

create index memories_user_idx on memories(user_id);

create index memories_embedding_idx on memories

using ivfflat (embedding vector_cosine_ops) with (lists = 100);

-- Row-Level Security: each user sees only their own memories

alter table memories enable row level security;

create policy "users see their own memories" on memories

for all using (auth.uid() = user_id);

Code.

-- Combined SQL + vector query (Supabase / Postgres)

select id, content, metadata, embedding <=> $1 as distance

from memories

where user_id = \$2

and created_at > now() - interval '30 days'

and importance > 0.4

order by embedding <=> $1  -- cosine, matches vector_cosine_ops

limit 10;

Source: github.com/pgvector/pgvector (PostgreSQL License; C)

Intent

Add vector data types and similarity search operators to Postgres, so any Postgres deployment can serve as both a relational store and a vector memory store.

Motivating Problem

Many teams have Postgres in their stack and don’t want to add a separate vector database alongside it. Until pgvector matured, the choice was painful: keep adding to Postgres and use external services for embedding search, or replicate state into a vector-aware system and live with the synchronization burden. pgvector eliminates the choice: install one extension, get vector columns, vector indexes, and similarity-search operators in the same Postgres.

How It Works

CREATE EXTENSION vector; gives you a vector type with configurable dimensions. Tables hold vector columns alongside normal columns. Two indexes are available: HNSW (slower build, better speed-recall trade-off, the default for most workloads) and IVFFlat (faster build, lower recall, good up to a few million rows). Operators: <-> (L2 distance), <#> (negative inner product), <=> (cosine distance), <+> (L1 distance), and <~> (Hamming) and <%> (Jaccard) for binary vectors. The halfvec and sparsevec types cut storage for large embeddings.

The performance ceiling is real and worth understanding. pgvector with HNSW comfortably handles tens of millions of vectors with sub-100ms query latency on appropriate hardware; pure Postgres at hundreds of millions of vectors starts to need careful tuning that competes with what dedicated vector stores handle automatically. The agent memory workload --- typically a few million memories per very-active deployment --- sits comfortably within the comfortable range.

When to Use It

Any Postgres deployment that needs vector search. The default for AI agent applications until vector volume forces a dedicated vector store. Particularly compelling when the relational state and the vector memory share the same per-user isolation requirements and Postgres RLS becomes the enforcement layer.

Alternatives --- Supabase (above) for the managed-Postgres path. Dedicated vector stores (Section B) when vector volume exceeds what pgvector handles. The choice is operational: one database vs two.

Sources

• github.com/pgvector/pgvector

Source: github.com/getzep/graphiti (Apache-2; Python)

Intent

Build a temporal graph of entities, relationships and facts from conversations and business data, where every fact has a validity window, so an agent can ask what is true now and what was true at any earlier point.

Motivating Problem

Memory staleness (Chapter 5, Appendix C) is a graph problem as much as a retrieval one: a user’s employer, a project’s owner, a customer’s plan all change, and a memory store that overwrites loses the history while one that appends keeps contradictory facts side by side. Batch graph-building approaches recompute the graph when data changes, which does not fit a store that is written on every turn. Graphiti updates the graph incrementally and keeps the timeline of each fact.

How It Works

Data enters as episodes: a message, a document, a JSON record. An LLM extracts entities and relationships from each episode and merges them into the graph without recomputing it. Each fact carries a validity window (when it became true and when, if ever, it was superseded). When information changes, the old fact is invalidated, not deleted, so queries can target the present or any point in the past. Every entity and relationship traces back to the episodes that produced it.

Retrieval is hybrid: semantic similarity, keyword search and graph traversal. Supported backends are Neo4j 5.26, FalkorDB, and Amazon Neptune (with OpenSearch Serverless for full-text search); Kuzu support is deprecated. The repository includes reference MCP and REST servers, which have no authentication or authorization and are not production deployments. Zep is the managed platform built on Graphiti (Section C).

When to Use It

Agent memory where facts change and their history matters (customer accounts, project state, relationships between people). Teams that want a self-hosted graph memory and can run a graph database. Cases where Appendix C’s staleness problem is a real risk.

Alternatives --- Zep for Graphiti as a managed service. Mem0 Platform graph memory for a hosted graph without running a database. Volume 10, Microsoft GraphRAG, for building a graph over a static corpus.

Sources

• github.com/getzep/graphiti

• help.getzep.com

Source: github.com/snap-research/locomo ; github.com/xiaowu0162/LongMemEval ; github.com/mem0ai/memory-benchmarks

Intent

Measure whether a memory system can recall, update and reason over information spread across many sessions, using shared datasets so results from different systems can be compared.

Motivating Problem

Memory-layer evaluation was spotty until recently: each vendor tested its own scenarios, and embedding benchmarks such as MTEB measure single-query retrieval, not whether an agent remembers that a user changed jobs three sessions ago. The field has converged on a few public benchmarks built from long conversations, and Mem0, Zep and Letta now publish results against them.

How It Works

LoCoMo (Snap Research, ACL 2024) is a dataset of very long-term conversations, each averaging 300 turns and 9K tokens over up to 35 sessions, with tasks for question answering, event summarization and multimodal dialogue generation. Memory evaluations mostly use its question-answering set (about 300 questions over 10 conversations in Mem0’s harness), covering factual recall, temporal reasoning and multi-hop inference.

LongMemEval (ICLR 2025) has 500 questions testing five long-term memory abilities: information extraction, multi-session reasoning, knowledge updates, temporal reasoning and abstention. It comes in variants with different history lengths.

BEAM targets extreme scale: conversations in size buckets from 100K to 10M tokens, with 2,000+ questions across ten memory ability types. Its evaluation cost is high.

Reported scores are not directly comparable across vendors. Mem0’s 2026 report gives Mem0 92.5 on LoCoMo and 94.4 on LongMemEval at about 6,900 tokens per query, and lists Zep and Letta results from their own publications under different models and configurations. The same report names the variables that move scores: the answering model, retrieval depth, reranking, the prompt wrapping retrieved context, and how lenient the LLM judge is. Mem0’s memory-benchmarks repository runs all three benchmarks, but only against Mem0 Cloud and Mem0 OSS; other systems need their own adapters.

When to Use It

Choosing a memory layer, and checking a vendor’s claims by rerunning a benchmark under a disclosed model and judge. Regression testing a memory pipeline after changing extraction prompts or retrieval settings. LongMemEval in particular when knowledge updates (the staleness problem) matter.

Alternatives --- build domain-specific evaluations against the team’s actual workload, which is always the most accurate measure but more expensive. Volume 8 covers evaluation tooling in general.

Sources

• github.com/snap-research/locomo

• github.com/xiaowu0162/LongMemEval

• github.com/mem0ai/memory-benchmarks

• mem0.ai/blog/state-of-ai-agent-memory-2026

Appendix A --- Memory Kind Reference Table

Cross-reference between the four kinds of memory (Chapter 1) and their representative substrates.

Appendix B --- The Series

This catalog is Volume 6 of the Agentic AI Series. The series started as six volumes (patterns, skills, tools, events and triggers, fabric, memory) and has grown since; the current list of volumes is at agentforce.cloud. The volumes are independent and the cross-references make any reading order coherent. The ones this volume points to most often:

• Volume 2, The Claude Skills Catalog: procedural memory in packaged form.

• Volume 3, The AI Agent Tools Catalog: the memory tool, Anthropic’s client-side memory primitive that an agent calls.

• Volume 4, The AI Agent Events & Triggers Catalog: durable execution for agent runs that must survive failures (Temporal, Restate, Inngest).

• Volume 5, The AI Agent Fabric Catalog: Microsoft Agent Framework, AWS Bedrock AgentCore.

• Volume 9, The Multi-Agent Coordination Catalog: LangGraph (multi-agent) state and checkpoints, and the blackboard pattern with its shared-scratchpad variant.

• Volume 10, The Retrieval Catalog: embedding models, MTEB, Microsoft GraphRAG, Neo4j with vector indexes.

Appendix C --- The Open Problems

Two problems are open at the memory layer in mid-2026, and worth keeping in view when designing for the next eighteen months:

1. Cross-session identity resolution. The memory model assumes a stable user_id. Anonymous sessions, multi-device users, and mixed authentication flows break the assumption. When two interactions arrive without confident user identification, are they the same person, and how confidently? Mem0’s 2026 report calls this out as an unsolved identity problem at the memory layer. The fix likely lives at the fabric layer (Volume 5’s identity story) but the memory layer has to live with the consequences.

2. Memory staleness. A high-relevance memory about a user’s employer is accurate until they change jobs, at which point it becomes confidently wrong. Decay handles low-relevance memories; staleness in high-relevance memories is harder. The current mitigations --- freshness scoring, explicit revocation, periodic re-verification against the user, and temporal graphs such as Graphiti that record when each fact stopped being true --- all have failure modes. Expect significant research and product activity here over 2026—2027.

Three additional questions are less open but worth deciding deliberately for any production deployment: (a) what counts as a memory-worthy observation, (b) how aggressively to compact, and (c) the per-user privacy and retention story. These are policy decisions, not architecture decisions, and the catalog can’t answer them --- but a serious deployment must.

Appendix D --- Discovery and Evaluation

Hubs for the agent-memory ecosystem:

• Mem0’s State of AI Agent Memory 2026 --- the field’s best annual snapshot, with framework integration counts, vector-store coverage, and benchmark results.

• MTEB leaderboard (huggingface.co/spaces/mteb/leaderboard) --- the canonical embedding model ranking; Volume 10 covers it.

• Mem0 memory-benchmarks (github.com/mem0ai/memory-benchmarks) - Mem0’s open-source harness that runs LoCoMo, LongMemEval and BEAM against Mem0 Cloud and OSS.

• Anthropic memory tool (platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool) - client-side, file-based memory under /memories that persists across conversations.

• LangChain memory concepts (docs.langchain.com/oss/python/concepts/memory) - short-term and long-term memory in the LangChain and LangGraph ecosystem.

Two pragmatic recommendations. First, run your own evaluation on your own data: published benchmarks (MTEB, LoCoMo and LongMemEval included) systematically favor the workloads they’re designed around, and your deployment’s domain may invert the rankings. Second, treat memory as a layer that will evolve faster than the rest of your stack; the products in this catalog will look different in twelve months, and the architecture you build should accommodate that.

Appendix E --- Omissions

This catalog covers 17 substrates across 7 sections. The wider ecosystem is much larger; a non-exhaustive list of what isn’t here:

• Conventional databases when used purely for relational state without any memory framing (most of Postgres, all of MySQL, MongoDB). The agent angle is required for inclusion.

• RAG over static document corpora (most enterprise knowledge-base products). The read-only RAG case is conventional and well-documented; this volume focuses on the read-write memory case.

• Caching layers (Memcached, conventional Redis) in their non-agent-memory roles.

• Specialized memory products for narrow use cases (browser-history memory, voice-call memory, screenshot memory) that haven’t consolidated into general-purpose categories yet.

• Vector databases optimized for non-text modalities (image search, audio search) when not used as agent memory backends.

• Embedding models, rerankers and graph-construction pipelines for static corpora; Volume 10 covers them.

Appendix F --- A Note on the Moving Target

Mem0 passed 67k GitHub stars in 2026, after consolidating EmbedChain and adding Graph Memory, which has since moved to the hosted Platform while the open-source library switched to ADD-only extraction with hybrid retrieval. Letta (formerly MemGPT) productized the original 2023 paper into a hosted platform and SDK, then moved agent memory into git-backed files. Zep introduced Graphiti for temporal knowledge graphs and now runs as a managed service with Graphiti as its open-source engine. AWS and Google Cloud began selling agent memory as a managed service. CrewAI replaced its separate memory types with one unified memory on LanceDB. Pinecone migrated to serverless pricing. pgvector matured into a production-default extension for Postgres deployments. The Anthropic memory tool became an API primitive for file-based memory that persists across conversations. The category is moving fast; this catalog captures a moment.

The deepest structural fact: the four kinds of memory (working, episodic, semantic, procedural) and the six-stage lifecycle (write, index, retrieve, update, compact, forget) are stable. The products that implement them will keep changing. An architect who internalizes the conceptual vocabulary can map any new product onto the framework in minutes and choose well; an architect who learns only the products has to relearn the field every twelve months.

The rest of the series is listed at agentforce.cloud.

--- End of The AI Agent Memory Catalog v0.1 ---