Skip to main content

​
Contract status

Canonical interface contract The OS and platform docs are explicit about memory categories, retrieval behavior, and shared access expectations. The storage implementation is intentionally swappable.

​
Source documents

​
Memory classes

The OS documentation defines four persistent memory classes:
Memory classMeaning
EpisodicWhat happened, and when
SemanticWhat the system learned about a domain
SomaticLearned behavioral patterns and preferences
EmotionalRelationship history, mood, and preference evolution

​
Foundation memory scope

The platform foundation PRD narrows the first build to:
  • Session memory
  • User memory
  • Tenant memory
  • Module memory
This means the first production service should be a stable shared data layer and API contract, even before the full Neurigraph reasoning layer is complete.

​
Required memory resources

ResourcePurpose
memory_entriesTyped units of stored memory
memory_indexesRetrieval and search structures
memory_linksAssociation edges across topics, contacts, and artifacts
recall_filesArchived conversation bundles and artifacts
memory_preferencesDurable user or tenant preferences
memory_artifactsLinked files, outputs, and supporting material

​
Required memory operations

  • Write a memory entry with type and scope
  • Search memories by semantic, temporal, and scoped filters
  • Retrieve a recall bundle for a persona or thread
  • Link new facts or artifacts to existing memories
  • Mark memory relevance, retention, or archive status
  • Expose module-safe reads and writes through a common service

​
Required scoping dimensions

Every memory write must carry enough context to prevent leakage:
  • persona_id
  • instance_id
  • workspace_id
  • memory_type
  • source_module
  • actor
  • created_at

​
Retrieval expectations

The OS docs describe a retrieval flow that mixes:
  • Temporal indexing
  • Semantic similarity
  • Pattern matching
  • Emotional relevance
Even if the first release simplifies ranking, the API contract should leave room for all four inputs.

​
Shared module behavior

The foundation PRD requires module memory to be shared. That means:
  • Voice can write call outcomes into shared memory.
  • Chat can read the same business context and prior conversation cues.
  • Knowledge can publish structured updates that influence later interactions.
  • Persona behavior can adapt based on long-lived preference signals.
{
  "query": "recent legal intake preferences",
  "workspace_id": "ws_123",
  "instance_id": "inst_456",
  "persona_id": "prs_789",
  "filters": {
    "memory_types": ["episodic", "semantic"],
    "source_modules": ["logiclegal", "voice"],
    "lookback_days": 90
  }
}

​
Implementation note

Do not hide memory behind one opaque transcript blob. The repo repeatedly calls for structured, typed, queryable memory.
Last modified on April 18, 2026