<!--
  Full-page Markdown export (rendered HTML → GFM).
  Source: https://neotoma.io/fr/types/events
  Generated: 2026-04-01T11:48:48.058Z
-->
# Events

Meetings, milestones, and the outcomes attached to them. Events in Neotoma tie together participants, decisions, and follow-up actions - so the context from a meeting persists beyond the session where it happened.

## Store[#](#store)

Store a event with any fields that describe it. Neotoma auto-discovers the schema from the first observation - no migration required.

MCP

store\_structured({ entities: \[ { entity\_type: "event", title: "Q4 Planning - Engineering", event\_type: "meeting", date: "2026-03-28T10:00:00Z", participants: \["Sarah Chen", "Alex Rivera"\], outcome: "Agreed on PostgreSQL migration timeline", follow\_ups: \["Draft migration RFC", "Set up staging env"\] } \], idempotency\_key: "event-q4-planning-eng-20260328" })

CLI

neotoma store --json='\[{ "entity\_type": "event", "title": "Q4 Planning - Engineering", "event\_type": "meeting", "date": "2026-03-28T10:00:00Z", "participants": \["Sarah Chen", "Alex Rivera"\], "outcome": "Agreed on PostgreSQL migration timeline", "follow\_ups": \["Draft migration RFC", "Set up staging env"\] }\]'

REST API

curl -X POST http://localhost:3080/api/store \\ -H "Content-Type: application/json" \\ -d '{ "entities": \[{ "entity\_type": "event", "title": "Q4 Planning - Engineering", "event\_type": "meeting", "date": "2026-03-28T10:00:00Z", "participants": \["Sarah Chen", "Alex Rivera"\], "outcome": "Agreed on PostgreSQL migration timeline", "follow\_ups": \["Draft migration RFC", "Set up staging env"\] }\] }'

Common fields for `event`:

| Field | Example |
| --- | --- |
| title | "Q4 Planning - Engineering" |
| event\_type | "meeting" |
| date | "2026-03-28T10:00:00Z" |
| participants | \["Sarah Chen", "Alex Rivera"\] |
| outcome | "Agreed on PostgreSQL migration timeline" |

Fields are flexible - add any property your workflow needs. The schema evolves automatically via [progressive schema enforcement](/schema-management).

## Retrieve[#](#retrieve)

Query events by type, search by keyword, inspect version history, and traverse relationships.

CLI

\# List recent events neotoma entities list --type event # Search by title neotoma entities search --query "Q4 Planning" --type event # See how meeting notes evolved neotoma observations list --entity-id <entity\_id> # Find linked participants and follow-up tasks neotoma relationships list --entity-id <entity\_id>

MCP

// Find by title retrieve\_entity\_by\_identifier({ identifier: "Q4 Planning - Engineering", entity\_type: "event" }) // List events in a date range list\_timeline\_events({ entity\_type: "event", start\_date: "2026-03-01", end\_date: "2026-03-31" }) // Expand related entities retrieve\_related\_entities({ entity\_id: "<entity\_id>", relationship\_types: \["REFERS\_TO"\] })

## What your agent can answer[#](#example-queries)

With events stored in Neotoma, your agent can answer questions like:

-   “What was decided in the Q4 planning meeting?”
-   “Show all meetings with Sarah this month”
-   “Which follow-ups came out of the engineering sync?”

## What Neotoma guarantees[#](#guarantees)

Every event stored in Neotoma gets the same set of integrity guarantees:

-   Versioned history - Every change creates a new version. Previous states are always accessible.
-   Deterministic state - Same observations always produce the same entity snapshot.
-   Auditable provenance - Every field traces back to the observation that set it.
-   Schema validation - Fields conform to the discovered or defined schema.

See all [memory guarantees](/memory-guarantees) compared across memory models.

## Next steps[#](#next-steps)

-   [Install Neotoma](/install) \- get started in 5 minutes
-   [Walkthrough](/developer-walkthrough) \- full multi-session example
-   [Personal data use case](/personal-data) \- see how events fit into a broader workflow