<!--
  Full-page Markdown export (rendered HTML → GFM).
  Source: https://neotoma.io/es/memory-models
  Generated: 2026-04-01T11:48:53.015Z
-->
# Memory models

AI agent memory falls into five categories: platform memory (Claude, ChatGPT), retrieval memory (Mem0, Zep), file-based memory (Markdown, JSON), database memory (SQLite, Postgres), and deterministic memory (Neotoma). Each makes different guarantees about consistency, versioning, and auditability.

Compare memory models first, then evaluate representative tools inside each model. This keeps the focus on guarantees and failure modes rather than brand checklists.

On this page

-   [Platform memory](#platform-memory)
-   [Retrieval memory](#retrieval-memory)
-   [File-based memory](#file-based-memory)
-   [Database memory](#database-memory)
-   [Deterministic memory](#deterministic-memory)
-   [Memory model comparison](#memory-model-comparison)

## Platform memory

Platform memory is the built-in memory provided by model vendors ([Claude](/neotoma-with-claude), [ChatGPT](/neotoma-with-chatgpt), Gemini, Copilot). It is convenient but opaque: storage and eviction policies are controlled by the provider.

Typical behavior: you ask a model to remember a preference, and future sessions may include it. There is rarely an append-only log, typed schema enforcement, or deterministic replay capability.

User: "Remember I prefer morning meetings."
Model platform: stores preference internally
Operator: cannot inspect full lineage, replay state transitions, or export a deterministic log

For production agent workflows, this model typically fails key guarantees in the comparison table (versioning, replay, audit, and deterministic resolution). Compare with [retrieval memory](#retrieval-memory) and [deterministic memory](#deterministic-memory).

◆

## Retrieval memory

Retrieval memory reconstructs context at query time (RAG/vector search). It excels at relevance search, but does not guarantee deterministic or complete state reconstruction.

Similarity ranking is sensitive to embeddings, chunking, and index updates. The same intent can return different top-k items over time.

Query A: "How should I schedule with Ana?"
-> top-k returns preference "morning meetings"

Query B: "Summarize Ana's profile"
-> top-k may omit that same preference

This model can satisfy semantic search needs but not core state-integrity guarantees. See [platform memory](#platform-memory), [deterministic memory](#deterministic-memory), [conflicting facts risk](/memory-guarantees#conflicting-facts-risk), and the [comparison table](#memory-model-comparison).

◆

## File-based memory

File-based memory stores state in Markdown, JSON, or similar artifacts. It is portable and easy to edit directly, but integrity guarantees are manual.

Typical implementations append notes or overwrite JSON blobs. Without a deterministic reducer and observation lineage, teams rely on ad-hoc conventions for conflict handling.

{
  "contact": "Ana Rivera",
  "city": "Barcelona"
}

# Later overwrite
{
  "contact": "Ana Rivera",
  "city": "San Francisco"
}

This model can work for lightweight workflows but usually fails deterministic guarantees at scale. See [platform memory](#platform-memory), [deterministic memory](#deterministic-memory), [schema constraints](/memory-guarantees#schema-constraints), and the [comparison table](#memory-model-comparison).

◆

## Database memory

Database memory uses a relational database (SQLite, Postgres, MySQL) with standard CRUD operations to store agent state. It provides strong consistency, column-level type enforcement, and fast structured queries.

The standard approach is to UPDATE rows in place. This gives you the current state but loses previous values unless you build audit tables, trigger-based history tracking, or an event log on top. Without that additional architecture, a database is a mutable snapshot store.

\-- Agent A writes a value
UPDATE contacts SET city = 'Barcelona' WHERE name = 'Ana Rivera';

-- Agent B overwrites it
UPDATE contacts SET city = 'San Francisco' WHERE name = 'Ana Rivera';

-- Previous value is gone. No conflict detection, no history.
SELECT city FROM contacts WHERE name = 'Ana Rivera';
-- → 'San Francisco'

Databases are familiar and powerful, but standard CRUD usage actively works against memory guarantees. You can build versioning, audit trails, and conflict detection on top of a database, but at that point you are building the observation/reducer architecture that Neotoma already provides. See [deterministic memory](#deterministic-memory), [silent mutation risk](/memory-guarantees#silent-mutation-risk), and the [comparison table](#memory-model-comparison).

◆

## Deterministic memory

Deterministic memory enforces state integrity through deterministic reduction, immutable history, schema validation, and provenance. Neotoma is the reference implementation.

Invariant stack: versioning, replay, auditability, and schema constraints. Together these guarantees make memory reproducible under load, across tools, and across time.

\# Store from one interface
neotoma store --json='\[{"entity\_type":"task","title":"Finalize architecture review","status":"open"}\]'

# Retrieve from another interface (MCP/CLI/API) and get identical canonical snapshot
neotoma entities list --type task --limit 5

Compared with platform, retrieval, and file-based models, deterministic memory prioritizes guarantees over convenience defaults. See [platform memory](#platform-memory), [retrieval memory](#retrieval-memory), [file-based memory](#file-based-memory), and [deterministic state evolution](/memory-guarantees#deterministic-state-evolution).

◆

## Memory model comparison

### [Platform memory](#platform-memory)

**[Claude](/neotoma-with-claude), [ChatGPT](/neotoma-with-chatgpt), Gemini, Copilot.** These are the built-in memory features offered directly by model providers. They manage memory behind the scenes, typically as convenience layers tied to a specific product. Platform memory is the easiest to adopt but the hardest to audit, version, or port between providers.

### [Retrieval memory](#retrieval-memory)

**Mem0, Zep, LangChain Memory.** These systems reconstruct context at query time by embedding past interactions and retrieving the most similar results. They excel at surfacing relevant context but introduce non-determinism: the same question asked twice may surface different facts depending on index state and re-ranking.

### [File-based memory](#file-based-memory)

**Markdown files, JSON stores, CRDT docs.** File-based approaches store memory as plain artifacts on disk or in collaborative documents. They are simple and human-readable, but lack schema enforcement, conflict detection, and audit trails unless those are layered on manually.

### [Database memory](#database-memory)

**SQLite, Postgres, MySQL.** Relational databases provide strong consistency, column-level types, and fast queries. But standard CRUD usage (UPDATE in place) erases previous state. Without an event log, audit tables, or observation architecture layered on top, databases are mutable snapshot stores with no built-in versioning, conflict detection, or provenance.

### [Deterministic memory](#deterministic-memory)

**Neotoma.** Deterministic memory systems guarantee that the same observations always produce the same entity state. Every fact traces to provenance, every state transition is versioned, and the full history is replayable. Neotoma is the reference implementation of this model, providing the [deterministic state evolution](/memory-guarantees#deterministic-state-evolution), [versioned history](/memory-guarantees#versioned-history), and [auditable change log](/memory-guarantees#auditable-change-log) guarantees that production agents require.