Memory families
Six architectural families, each with a different core idea about what memory is — a derived user model, an extracted fact store, a graph, a folder of markdown, a runtime subsystem, or a library. Each family page explains what makes it unique against the others and lists the use cases it is built for.
Models a person or agent, not a pile of facts.
These systems maintain an evolving model of the user (or of an agent, or of an idea) by reasoning in the background over what they have observed. They infer preferences, beliefs, and contradictions rather than only storing stated facts. Recall is less keyword-match and more 'what would this user likely need here' — the gap between recalling a stated preference and predicting a reaction.
2 frameworks · 3 use cases
An LLM extracts discrete memories; you recall them by semantic search.
An LLM reads your interactions and extracts discrete memories — facts, preferences, events — into a store. Recall is by semantic search over that store, often behind a hosted API you call rather than run yourself. The vendor typically owns the extraction logic and the embeddings pipeline. This is the most crowded family: fast to drop in, large integration ecosystems, dual session/user scope, and the production-polish end (SOC2/HIPAA, connectors, context fencing, sub-300ms) lives here too.
14 frameworks · 5 use cases
Memory as entities and relationships; recall traverses the graph.
Memory is stored as entities and the relationships between them, forming a graph rather than a flat list. Recall traverses the graph, which makes multi-hop questions ('who worked on the project that depended on X?') answerable without re-reading everything. Two distinct sub-shapes live here: bi-temporal graphs where every fact carries validity windows and stale facts auto-supersede ('what's true now + how it changed'), and GraphRAG engines that ingest a large corpus into an ontology-grounded graph and reason over it toward a conclusion.
7 frameworks · 3 use cases
Memory as plain files on disk — readable, editable, version-controllable.
Memory lives as plain files — usually Markdown — that the agent reads and writes directly on disk. There is no database or embedding service; the agent treats memory the way it treats any other file it can open and edit. This keeps memory human-readable, git-friendly, and cheap, at the cost of scale and automatic semantic search. Some members add tiered context (L0→L2 loading) for token savings, or pre-compression capture hooks that grab decisions before a long session is summarized away.
7 frameworks · 5 use cases
Memory built into a stateful agent runtime as a first-class subsystem.
Memory is built into a stateful agent runtime as a first-class subsystem, not a separate library you bolt on. The runtime manages when to store, what to keep, and when to inject context back in, often alongside skills, sessions, and user profiles. You get memory by adopting the whole agent, not by wiring a component into your own. The strongest member models memory as RAM/cache/disk that the agent itself manages inside its own reasoning loop, and can self-edit its core memory over long horizons.
3 frameworks · 1 use case
A memory toolkit you import and wire into your own agent stack.
A memory toolkit you import and wire into your own agent stack, keeping control of where data lives. You call its APIs to store and recall; it does not impose a runtime or a hosting model. Storage and retrieval are yours to deploy, which is the main trade-off versus a managed offering. The standout capability here is procedural memory — learning how to do a recurring task and rewriting the agent's own prompts or behavior from past episodic successes.
11 frameworks · 1 use case