Skip to main content
MemoryOS is the governed state and context layer for production AI agents. Your backend sends relevant conversations, corrections, and application events to MemoryOS, then retrieves current, authorized context before the next model call. Databases store business records. Transcript stores preserve conversations. Vector search finds similar records. MemoryOS governs learned state: what became durable, what changed, which claim is current, where it came from, and which agent may reuse it.

​
Where MemoryOS fits

MemoryOS works alongside your existing infrastructure: MemoryOS is not a complete episodic archive, general document RAG system, agent framework, or replacement for your system of record.

​
The governed-context lifecycle

  1. Ingest relevant conversations, corrections, and application events.
  2. Extract candidate durable state and supporting evidence.
  3. Reconcile candidates with existing claims, revisions, and conflicts.
  4. Govern validity, provenance, authority, lifecycle, and access policy.
  5. Retrieve current, authorized, prompt-ready context.
MemoryOS decides what is durable enough to retain, keeps source and version history, and returns only the context relevant to the current request. Your application remains responsible for the conversation, model call, authoritative business data, and real actions.

​
Choose an integration

Memory Passport is a frozen private beta and is disabled by default. Its APIs return 404 memory_passport_not_available unless MemoryOS explicitly enables the feature for an approved design partner. Tenant memory remains the supported production path.

​
The tenant-memory loop

For most products, integration is two server-side calls:
  1. Call get() before your model call.
  2. Add system_prompt_addition when has_context is true.
  3. Always call your model, including when MemoryOS returns no context or passthrough mode.
  4. Call add() after the conversation turn or session you want MemoryOS to examine.
add() accepts a conversation, not a prewritten memory. Extraction runs asynchronously, so a queued response confirms acceptance rather than immediate storage.

​
What MemoryOS stores

The General Engine can extract durable information such as preferences, goals, recurring procedures, relationships, stable facts, and demonstrated expertise. Uncertain signals may remain pending until later evidence reinforces them. Temporary instructions and conversational filler should not become long-term memory. Domain schemas use the same add() and get() calls while adding structured domain context. EdTech can maintain learning profiles; Support can maintain customer-support context. Keep grades, payments, ticket state, permissions, and other authoritative business records in your own systems.

​
Multiple services and agents

Use the same external_user_id whenever your services refer to the same person. Register a service writer for each production writer and attach a stable source event ID to writes. This gives MemoryOS enough provenance to deduplicate retries, compare authority, preserve lineage, and route genuine conflicts. Conflicts do not all follow the same path: trusted evidence may resolve automatically, tenant-owned conflicts may require dashboard review, and the frozen Memory Passport private beta has a separate user-clarification path when explicitly enabled. Each conflict has one resolution path.

​
Memory Passport

Memory Passport is an experimental design for consent-based memory shared across independent agents or applications. It is currently frozen as a private beta while the normal tenant-memory path remains the production focus. Do not build a production integration against Passport unless MemoryOS has explicitly enabled it for your tenant. A normal integration uses an API key plus your stable external_user_id; it does not redirect users to MemoryOS or require a consent button.

​
Production boundaries

  • Call MemoryOS from your backend; never expose API keys in browser or mobile code.
  • Use stable pseudonymous user IDs rather than email addresses.
  • Treat retrieved memory as context, not authorization or transactional truth.
  • Use source metadata for retries and multi-service writes.
  • Continue serving users when memory is empty, delayed, degraded, or unavailable.

​
Start building