ভিত্তি
Neotoma is built on four architectural commitments: your data stays on your machine, the same input always produces the same output, history is append-only and verifiable, and your memory works across every AI tool you connect. These are not feature flags; they are structural properties of the system.
গোপনীয়তা-প্রথম
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. Nothing is stored unless you approve it: there is no background scanning, no implicit captures, and no opt-out telemetry. You decide what goes in. 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: by default, data stays on your machine. When hosted deployment is needed, the operator controls the infrastructure and data location.
See deterministic memory for the state evolution model and architecture for the full system design.
নির্ণায়ক
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. For unstructured files, AI interpretation extracts fields present in the source with full audit trail and idempotence guarantees; it does not synthesize or infer data beyond what the source contains. Corrections add new observations rather than editing existing ones.
This matters because agents that read stale or conflicting state make wrong decisions. With a single agent, write corruption degrades quality gradually. With multiple agents sharing state, one bad observation propagates at machine speed—triggering downstream actions before any human can intervene. 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.
অপরিবর্তনীয় ও যাচাইযোগ্য
Every observation is append-only. History cannot be rewritten. Corrections add a new observation that supersedes earlier ones in the reducer; the prior values remain on disk and remain replayable, with the agent or user that authored each value attributed on the row.
Entity IDs are content-addressed hashes derived from canonical identity fields. The same logical record resolves to the same ID across stores, processes, and machines, and any tampering with the underlying observation chain is detectable. There is no mutable surrogate key that can be silently re-pointed at different state.
Every entity carries a full provenance chain back to its source: the file or tool that produced an observation, the interpretation run (if any) that extracted it, the timestamp, and the priority that won during reduction. You can ask "where did this fact come from?" of any field on any entity and get an exact, reconstructable answer.
This is what makes Neotoma trustworthy as the state layer underneath agent action. When an agent takes a consequential step, the basis for that step is verifiable after the fact, even if the underlying source moved or the operating environment changed.
See versioned history and auditable change log for the per-guarantee details, and architecture for how immutability is enforced across the pipeline.
ক্রস-প্ল্যাটফর্ম
Neotoma provides one memory system across AI tools. Claude, ChatGPT, Cursor, Codex, OpenCode, Claude Code, OpenClaw, and IronClaw 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, Codex, and OpenCode.