<!--
  Full-page Markdown export (rendered HTML → GFM).
  Source: https://neotoma.io/what-to-store
  Generated: 2026-05-04T09:49:32.457Z
-->
# 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.

1.  Recallability: Would an agent or user need this fact again in a future session?
2.  Auditability: Would someone need to know when this was recorded or how it changed?
3.  Reproducibility: Would reconstructing past state require this fact?
4.  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](/install), then [follow the walkthrough](/walkthrough) to see storage in action. See [backup and restore](/backup) to protect your data.