Agent memory: five approaches, honestly compared
There are five common approaches to AI agent memory: built-in platform memory, RAG/retrieval, file-based notes, a conventional database, and an event-sourced log. Every team picks one, usually by accident. This page sets out where each approach wins, where each breaks down, and how to choose deliberately.
Choose by evidence need
These are approach-level trade-offs, not guarantees about every product. Sources show representative implementations.
| Approach and source | Best fit and limitation |
|---|---|
| Platform memoryOpenAI Memory FAQ | Personalization inside one assistant Application decision history remains a separate design problem. |
| Retrieval / RAGMicrosoft RAG guidance | Finding relevant passages in a document corpus Answer quality depends on content preparation and retrieval configuration. |
| FilesClaude Code memory docs | Small, inspectable project instructions Structured queries and concurrent updates need additional tooling. |
| DatabaseMicrosoft event sourcing guidance | Structured current state and familiar CRUD Add application-level history when past decisions must be reconstructed. |
| Event-sourcedMicrosoft event sourcing guidance | Replayable changes and inspectable provenance Design event schemas and projections; semantic recall is another layer. |
Platform memory
Memory features built into the model vendor's product surface. You enable a setting, the assistant starts remembering across conversations.
- Zero configuration — turn it on in settings, done
- Native UX integrated with the chat interface
- No code, no infrastructure
- Locked to one vendor — your memory in Claude isn't available in ChatGPT
- API and export paths vary by provider and product
- Product memory history is not the same as your application's decision history
- Memory shape is decided by the vendor, not you
Retrieval / RAG memory
Store conversation chunks (or extracted facts) as vector embeddings; retrieve via semantic similarity at query time. The dominant pattern for the past two years.
- Works for unstructured content — chat logs, documents, notes
- Multi-tool friendly via REST APIs
- Semantic recall finds adjacent ideas, not just exact matches
- Similarity is not truth — the top match can be plausible and wrong
- Hard to verify what's in the store without querying with the right phrasing
- No first-class graph — relationships between facts are not modeled
- Point-in-time reconstruction needs timestamps, versions, and retrieval rules you design
File-based memory
Human-readable files in a folder. Agents read and edit them directly. Often committed to git so changes are reviewable.
- Trivial to inspect — open the file in any editor
- Version-controlled for free via git
- Zero infrastructure
- Works offline without a separate service
- Manual merge conflicts when two agents (or an agent and a human) edit the same file
- No structured queries — "all decisions involving Alice" requires grep
- No typed relations between facts
- Search, concurrent edits, and schema become your responsibility as the collection grows
Database memory
A relational table with rows for entities; the agent does CRUD via function-call tools. Leverages skills your team already has.
- Structured, queryable, durable
- Uses tooling your team already knows (migrations, ORMs, SQL)
- Constraints enforce schema at write time
- Every schema change is a migration
- Point-in-time business history needs a history model, not only current rows
- Relationships need schema and query design
- Semantic recall needs an embedding and indexing path
Event-sourced memory
AllSource PrimeMemory as an append-only log of events. Current state is projected from the log; full history is preserved. AllSource Prime adds a knowledge graph and vector recall on top of the same event spine.
- Replayable change history when complete events are captured
- Source-event provenance when writes record their evidence
- Graph + vector recall in one query (Prime's `prime_recall`)
- Hosted multi-tenant or local-first — same data shape both ways
- Cross-tool sync via MCP — same memory in Claude Desktop, the Anthropic CLI, Cursor, OpenCode
- More infrastructure than a markdown file or platform memory
- Conceptually different from CRUD (events, not rows) — learning curve
- Newer category — fewer drop-in tutorials than for Postgres or vector DBs
Need to test restart durability?
The comparison is a decision aid. Run a local write, restart, recall, and history check before choosing a memory layer for production.