Foundations
Neotoma is built on three architectural commitments: your data stays on your machine, the same input always produces the same output, and your memory works across every AI tool you connect. These are not feature flags — they are structural properties of the system.
Privacy-first
Your data stays on your machine. Neotoma runs locally — no cloud sync, no remote telemetry, no training on your data. The server is a process on your hardware, the database is a file on your disk, and the MCP interface exposes only what you choose to connect.
Storage is user-controlled at every level. You decide what goes in — nothing is stored implicitly. Observations are append-only and encrypted at rest when configured. Every entity traces to a source and timestamp, so you can audit exactly what the system knows and where it came from.
Full export and deletion are first-class operations. You can export your entire memory graph at any time, and deletion removes data — it does not mark it inactive or hide it behind a flag. There is no retention period and no "soft delete" that preserves data server-side.
This model means agents can build rich, structured memory without requiring trust in a third-party service. The privacy guarantee is architectural, not policy-based: there is no remote endpoint to breach because the data never leaves your machine.
See deterministic memory for the state evolution model and architecture for the full system design.
Deterministic
Same input always produces the same output. Entity IDs are hash-based, observations are append-only, and every state change is recorded with full provenance. There is no silent mutation and no implicit overwrite.
State evolves through a versioned pipeline: sources become observations, observations resolve to entities, entities produce versioned snapshots, and snapshots form the memory graph. Every stage is deterministic and inspectable. You can diff any two versions of an entity or reconstruct its full history from the observation log.
Schema-first extraction enforces structure at the boundary. Extraction rules derive from schema types, not heuristics. Fields are extracted from what is present in the source — nothing is inferred, predicted, or synthesized. Corrections add new observations rather than editing existing ones.
This matters because agents that read stale or conflicting state make wrong decisions. When state evolution is deterministic, every downstream action inherits a known, auditable basis. Debugging becomes reconstruction, not guesswork.
See memory guarantees for the full invariant set and architecture for how determinism is enforced across the pipeline.
Cross-platform
Neotoma provides one memory system across AI tools. Claude, ChatGPT, Cursor, Codex, Claude Code, and OpenClaw all access the same state graph through Model Context Protocol (MCP). Facts stored by one agent are immediately available to every other connected agent — no sync step, no export/import, no duplicate data.
MCP is the integration layer. Each AI tool connects to Neotoma's MCP server and uses the same store, retrieve, and relationship operations. The CLI and REST API expose the same OpenAPI-backed contract, so humans and apps have identical access. There is one source of truth regardless of the interface.
Neotoma works alongside native memory features — ChatGPT's memory, Claude's project knowledge, Cursor's context. It does not replace them or require disabling them. When you stop using Neotoma, there is nothing to uninstall from the AI tool itself; you simply disconnect the MCP server.
No platform lock-in. Your memory graph is a local SQLite database. You own the file, you control what connects to it, and you can export or migrate at any time. Switching AI tools does not mean starting over — the same structured memory is available to the next tool you connect.
See MCP reference for the full action catalog, CLI reference for terminal commands, and API reference for REST endpoints. For per-tool setup guides, see Cursor, Claude, Claude Code, ChatGPT, and Codex.