What to store first
Neotoma stores any structured fact that benefits from deterministic state evolution, versioning, and provenance. The deciding question is not “is this personal data?” but does this fact benefit from being versioned, auditable, and reproducible?
If an agent or user would later need to recall a fact, verify when it changed, trace why a decision was made, or reconstruct state at a point in time: it belongs in Neotoma.
Tier 1 - High-value facts
Store these proactively from the first session.
| Category | Examples |
|---|---|
| People and relationships | Contacts, companies, organizations, role connections |
| Commitments and tasks | Obligations, action items, deadlines, promises made |
| Events and decisions | Meetings, milestones, choices with rationale |
| Financial facts | Transactions, invoices, receipts, contracts, payments owed |
Tier 2 - Contextual facts
Store when encountered in conversation, documents, or external tools.
| Category | Examples |
|---|---|
| Preferences and standards | User preferences, conventions, style guides, stated constraints |
| Project context | Codebase entities, architectural decisions, release metadata, config |
| Documents and artifacts | Uploaded files with extracted structure, reports, specifications |
Tier 3 - Derived context
Store when the derived record carries future recall, audit, or relationship value.
| Category | Examples |
|---|---|
| Conversations | Agent interactions with provenance (persisted per-turn) |
| Session state | Active environment, running tools, current working context |
| External data | Records pulled from email, calendar, web, APIs, other MCPs |
Before-and-after examples
Contacts from a conversation
Before: You mention “Clayton from Acme” in a chat. Next session, the agent has no idea who Clayton is.
After: Agent stores a contact entity with name, company, and a REFERS_TO link to the conversation. Next session, Clayton’s full context is retrieved instantly.
Task from a commitment
Before: “I need to follow up with Sarah by Friday.” The commitment exists only in that session.
After: Agent stores a task entity with title, due date, and REFERS_TO Sarah’s contact. Task persists across sessions and tools.
Decision with rationale
Before: You decide on PostgreSQL over MySQL. Three weeks later, no one remembers why.
After: Agent stores a decision_note with rationale and context. The reasoning is versioned and traceable.
Decision heuristic
When deciding whether to store something, apply this test. If any answer is yes, store it.
- Recallability: Would an agent or user need this fact again in a future session?
- Auditability: Would someone need to know when this was recorded or how it changed?
- Reproducibility: Would reconstructing past state require this fact?
- Relationship value: Does this connect to other entities (people, tasks, events)?
What NOT to store
| Category | Examples |
|---|---|
| Ephemeral output | No future recall value; no benefit from versioning |
| Duplicate records | Already in Neotoma; check before storing |
| Inferred or predicted data | Neotoma stores facts, not guesses |
| Unapproved data | Explicit user control required |
| Credentials and secrets | Belong in secret managers, not state layers |
Ready to start? Install Neotoma, then follow the walkthrough to see storage in action. See backup and restore to protect your data.