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.
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
- No programmatic access — you can't query or export what's been remembered
- Limited or no audit trail / version 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
- "What did I tell you last Tuesday?" requires you to already know what to ask
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
- Scales poorly past a few hundred facts — the file becomes a wall of text the model can't parse efficiently
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
- No time-travel without bitemporal columns (`valid_from`, `valid_to`) and your own query layer
- No graph — adjacency requires explicit join tables you maintain
- Vector recall isn't there without bolting on pgvector or a sidecar
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.
- Time-travel by construction — "what did I know about X as of last Tuesday?" is a query
- Per-field provenance — ask "where did this value come from?" and get the source event, via MCP, REST, or any SDK
- 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
How to pick
- Single-user, single-tool, low volume? Platform memory or a CLAUDE.md file. Stop reading, start writing.
- Unstructured content, semantic search is the killer feature? Mem0 or Zep. Accept the truthiness tradeoff.
- Structured entities, no time-travel needs? Postgres + CRUD. You already know the playbook.
- Multi-tool, multi-user, audit-driven, or you want both graph and vector recall? Event-sourced. AllSource Prime is one of the few productized options in this category.