Choosing memory for AI agents.
Memory is not a feature you bolt on — it's a design decision that shapes every agent you build for years. There are six ways to do it, and each one is the right answer somewhere. This page walks all six honestly: what each buys you, what it costs, where it fails, and when we'd tell you not to use the thing we make.
No benchmark numbers on this page — the regimes aren't comparable, and qualitative judgment is more honest here. Every measured claim about Memomee lives on the comparison page, sourced to a committed run.
Six approaches, one matrix.
The whole decision at a glance. "Governance" is the axis to watch: it's the difference between storing memory and controlling what memory is allowed to do — approval, supersession, isolation, audit, forgetting.
| Approach | Setup complexity | Cost at scale | Governance | Maturity |
|---|---|---|---|---|
| Large context | None | Grows unbounded | None | Built-in |
| Summarization | Low | Low | None | Mature |
| RAG | Low–moderate | Low | None | Commodity |
| Graph memory | High | Moderate–high | Partial | Maturing |
| Memory stores | Low | Per-call pricing | Partial | Maturing |
| Memory control planes | Moderate | Compact reads | Full | Emerging |
Every row gets a full profile below — including where it fails and when to avoid it. Deliberately out of scope: prompt caching (a provider optimization, not memory), fine-tuning (changes the model, not its memory), and in-context learning (nothing persists between calls).
Large context · the ceiling
Keep the entire conversation — every turn, tool call, and result — in the model's context window on every request. The window is the memory.
- Nothing is lost to compression — the model sees everything, every time
- Zero infrastructure: no stores, no pipelines, no retrieval to get wrong
- The answer-quality ceiling on anything that fits — it's the bar every other approach is measured against
- You re-read — and re-pay for — the whole transcript on every single call
- Every window has a hard edge; long-running work outgrows it eventually, and then the approach stops existing
- Recall decays across very long inputs — content in the middle of a long context is recalled measurably worse (the documented 'lost in the middle' effect)
- No memory semantics: no update, no forget, no per-user isolation — the transcript is one undifferentiated mass
- Bounded sessions that comfortably fit the window
- Batch or offline analysis over a fixed document set
- Prototyping, before memory actually matters
- Agents that run for hours or days, or across sessions
- Cost-sensitive, high-frequency workloads — the bill scales with history
- Anything that must forget, redact, or isolate one user from another
Failure modes · Window overflow (a hard stop) · Mid-context recall decay · Cost blowout as history grows · No cross-session continuity
Conversation summarization · the compressor
Periodically compress the transcript into a running summary and keep only the last few turns raw. The summary becomes the memory.
- Roughly an order of magnitude cheaper than re-reading everything
- Preserves conversational gist across long sessions
- Simple to add to any chat loop; increasingly a built-in model primitive
- Lossy by design — what the summary drops is unrecoverable, and you don't choose what it drops
- Summaries drift: small omissions compound over generations of re-summarizing the summary
- No fact-level updates — 'the deadline moved' can't be patched into a paragraph; the old claim lives on inside it
- A single linear thread: branched or parallel work compresses into whichever thread the summarizer kept
- Chat assistants where gist-level continuity is enough
- Cost relief on long single sessions
- A first step once transcripts stop fitting the window
- Agents that must recall the exact decision, number, or commitment later
- Workflows that branch, pause, or resume — summaries are linear
- Anything audited: a summary is an assertion without its evidence
Failure modes · Summary drift · The decision that mattered gets compressed away · Branch loss · Unrecoverable detail
RAG · the floor
Embed chunks of history or documents, then retrieve the top-k most similar chunks for each query. Retrieval-augmented generation, pointed at the past.
- Scales to arbitrarily large corpora with fast, predictable, cheap reads
- The most mature tooling on this page — a commodity with a dozen hosted options
- Genuinely excellent at what it was built for: lookup over static knowledge
- A useful component inside a larger memory stack
- Similarity is not relevance — it misses temporal, causal, and recency structure ('what changed since yesterday' shares no words with its answer)
- No memory semantics: stale and current facts retrieve side by side, with no supersession and no conflict handling
- A bag of chunks — no task state, no procedures, no lineage, no idea what changed
- Multi-hop questions need facts chained across chunks; top-k similarity doesn't chain
- Stateless retrieval over documents — FAQ, knowledge bases, policy lookup
- Corpora that are large and mostly static
- As one retrieval channel among several, not the whole memory
- Evolving, per-user facts that supersede each other
- Agents that act on procedures and preferences, not just facts
- Questions that need two or more facts chained together
Failure modes · Retrieval mismatch (relevant to a different problem) · Stale-fact collision · Single-hop ceiling · Context pollution
Graph memory · the relationship engine
Extract entities and relationships into a graph with time-aware edges, then retrieve by traversal and association instead of similarity alone.
- The strongest answer to 'what do we know about X, and how did it change' — relationships and evolution are first-class
- Enables associative, multi-hop recall that pure similarity can't reach
- Provenance-friendly: edges carry where a claim came from and when it stopped being true
- Extraction quality gates everything — a noisy graph retrieves confident noise
- Real schema and ontology investment up front, and ongoing curation as the domain shifts
- The highest build-and-operate cost of the store-style approaches; traversal adds read latency
- Still a store: it holds memory well but doesn't govern which memory may shape an answer
- Entity-heavy domains — customer records, investigations, compliance
- Long-horizon user modeling where relationships carry the meaning
- Questions that are fundamentally about how things connect
- Task-state resumption as the primary pain — a graph of entities is not a checkpoint
- Teams without the ops budget to curate extraction quality
- Workloads with little meaningful entity structure
Failure modes · Extraction noise compounds into the graph · Schema rot as the domain shifts · Traversal latency at depth
Memory stores · the drop-in
A purpose-built memory service: send conversations in, get relevant memories back. The extract-and-store pipeline comes bundled.
- The fastest path from zero to persistent memory — someone else runs the pipeline
- A real improvement over DIY chunk-and-embed for conversational memory
- Simple developer experience; per-user memory in an afternoon
- Opinionated extraction you don't control — and can't easily audit
- Store-and-retrieve semantics: typically no approval gates, limited supersession and lineage, little visibility into what was injected and why
- Behavior-changing memory (learned procedures, preferences) usually isn't separated from plain facts — it all flows into context alike
- Black-box retrieval: when the agent acts on a bad memory, 'why did it know that?' has no good answer
- Chat assistants that need per-user continuity quickly
- Teams that don't want to operate memory infrastructure
- Prototypes that need real memory to be meaningful
- Regulated or audited environments
- Agents whose memory changes how they behave
- When you must answer 'why did the agent know that?' to a reviewer
Failure modes · Silent extraction errors · Stale memory quietly shaping answers · Unanswerable provenance questions
Memory control planes · the governor
Treats memory as a governed lifecycle rather than a store: capture everything in an append-only event ledger, derive typed memory (facts, decisions, procedures, preferences), gate what may shape answers behind approval and audit, retrieve across every substrate, and assemble a compact, provenance-backed context — with a trace for every answer.
- The only approach where governance is the product: behavior-changing memory is born pending until approved, facts supersede with lineage, conflicts trigger abstention instead of a guess
- Isolation enforced at the read path — one user's memory cannot surface in another's context, verified by automated gates
- Compact, typed context instead of a transcript — in our matched benchmarks, near-parity evidence recall at 5–11× fewer read tokens than a full-context reader (measured and sourced — link below)
- Raw history is preserved, so nothing is unrecoverable and every derived memory points back to its evidence
- The newest category on this page — the smallest ecosystem, the fewest vendors, patterns still standardizing
- More concepts to learn: a typed taxonomy, scopes, policies, approval flows
- Integration is a real surface (write events, read assembled context), not a one-line drop-in
- Answer quality is bounded by derivation quality — the extraction step is the lever, and it needs measuring
- Long-running agents that branch, get interrupted, or drift
- Agents whose learned procedures and preferences change how they behave
- Multi-user products where isolation, audit, and forgetting are hard requirements
- Regulated or reviewed environments — anywhere 'why did it know that?' must have an answer
- Short-session chat and static document QA — the governance buys nothing
- A prototype you need working today with zero integration
- Teams that only need 'remember what the user said last week'
Failure modes · Extraction quality bounds answer quality · Governance flows need operating (someone approves) · New-category risk
Real systems don't pick one. They layer them.
The production consensus is hierarchical memory: raw turns in the window, compressed memory between sessions, persistent stores for the long term — sometimes down to the humble markdown file the model keeps for itself. The approaches above are layers, not rivals. Which reframes the question: once every layer exists, who governs the stack? Which memory may shape the next answer — and who decided?
The current session's raw turns and tool calls live in the window. Cleared when the session ends — the fastest, most expensive memory there is.
Summaries, compaction, and extracted facts carry gist across sessions. Cheap and lossy — the layer where drift is born.
Vector, graph, and file stores hold the long term — including the humble markdown file (AGENTS.md and its peers, the model-written notebook pattern now standard in coding agents).
That governing layer is what a control plane adds — not another store, but the rules and evidence over all of them. It's also what makes the five ways agents lose the plot a management problem, not a storage problem.
If you're building X, reach for Y.
| If you're building… | Reach for |
|---|---|
| A prototype, or conversations that fit the window | Large context |
| Long chats where gist is enough | Summarization |
| Lookup over static documents | RAG |
| Entity and relationship questions over time | Graph memory |
| Per-user chat memory this week, minimal infra | A memory store |
| Long-running agents, audit, isolation, behavior-changing memory | A control plane |
Where we tell you not to buy our own product
Memomee is a memory control plane, and a control plane is overkill for short-session chat, static document QA, solo prototypes, or anything where memory doesn't change what the agent does. If that's you, rows one through five of the table above are the right call, and this page did its job. If your agents run long enough to branch, drift, or get reviewed — that's when the sixth row earns its complexity. The measured evidence is on /compare; the governance model is on /governance.
Pressure-test any memory stack — five questions
Whichever row you're on, these five questions expose the difference between storing memory and governing it. Ask them of any vendor — us included.
- 01When a fact changes, what happens to the old one? Overwritten in place — or kept, linked, and out of retrieval with a validity interval?
- 02Can a learned rule change what the agent does without a human approving it? If yes, you've found the governance gap.
- 03"Why did it know that?" Answerable from a record — what was injected, what was filtered, why — or only from log archaeology?
- 04Whose memory can leak into whose? Is isolation enforced in the query layer, or is it a prompt-level hope?
- 05What does memory cost at 100× the history? In tokens, in latency — and in drift, the cost nobody meters.