Skip to main content
MemoryOS now supports two memory domains:
  • tenant-scoped memories stored for a specific tenant plus external_user_id
  • universal memories stored for a Memory Passport user and shared only with agents that were granted access
The memory object shape is similar across both systems, but the identity and permission model is different.

Memory data model

Stored memory objects expose these fields in the public API:
FieldTypeMeaning
idstringMemory id
contentstringCanonicalized memory text
categorypreference | fact | goal | procedure | relationship | expertiseMemory type
importance_scorefloatRelative importance
original_importance_scorefloat | nullExtraction-time importance before boosts or decay
confidence_scorefloatExtraction confidence
created_atdatetime | nullCreation timestamp
updated_atdatetime | nullLast update timestamp
last_accessed_atdatetime | nullLast retrieval access time
access_countintRetrieval count
is_archivedboolWhether the memory is archived
is_hotboolWhether the memory is currently promoted to the hot tier
system_archivedboolWhether lifecycle manager auto-archived the memory
agent_idstring | nullOptional agent ownership
previous_version_idstring | nullPrior version link
source_conversation_idstring | nullSource conversation link
source_job_idstring | nullExtraction job that created the memory
metadataobjectCustom metadata

Tenant memory vs universal memory

DimensionTenant-scoped memoryUniversal memory
OwnerA tenant workspaceA Memory Passport user
User identityexternal_user_iduui_...
Access modelTenant API keyAgent API key + UUI grant
Primary use caseApp personalization inside one productCross-agent memory sharing with user consent
Isolation boundaryTenantUser plus granted categories

The six memory categories

CategoryExample
preference”User prefers concise technical explanations.”
fact”User works at Acme Robotics.”
goal”User is preparing for a cloud certification.”
procedure”User wants weekly summaries sent on Fridays.”
relationship”User reports to Priya on the data platform team.”
expertise”User is experienced with FastAPI and PostgreSQL.”

Importance scoring

importance_score is stored as a numeric value and influences ranking at retrieval time. Higher-importance memories are more likely to survive ranking and remain useful in cold-start retrieval.

Memory lifecycle

  1. Extracted Conversation content is analyzed from an ingestion job.
  2. Stored Valid extracted memories are written to the database and vector index.
  3. Retrieved Matching memories are ranked and returned to your app.
  4. Boosted or decayed Usage can increase live importance, while inactivity can reduce it.
  5. Hot promoted Frequently accessed, high-value memories can be cached in Redis.
  6. Archived Low-value inactive memories can be removed from search while remaining in PostgreSQL.
  7. Versioned Meaningful changes are recorded in append-only version history.
The lifecycle manager never hard-deletes memories. It only soft-archives them from search. GDPR delete is a separate explicit operation. Read Memory lifecycle and versioning for the full model.

Universal memory lifecycle

Universal memories follow the same extraction and ranking ideas, but with one extra rule:
  1. the user creates a Memory Passport
  2. an agent requests access to one or more categories
  3. the user grants or revokes access
  4. only then can that agent write or retrieve universal memories for that user
  5. revocation removes future access without exposing what other agents can see