MemoryOS is a memory layer for AI applications. Your backend sends completed conversations to MemoryOS and retrieves relevant context before the next model call.
MemoryOS decides what is durable enough to remember, keeps source and version history, and returns only the context relevant to the current request. Your application remains responsible for the conversation, model call, and authoritative business data.
Choose an integration
Tenant memory and Memory Passport are different security boundaries. A tenant API key cannot read Universal Memory, and an agent key does not grant access without the user’s active consent.
The tenant-memory loop
For most products, integration is two server-side calls:
- Call
get() before your model call.
- Add
system_prompt_addition when has_context is true.
- Always call your model, including when MemoryOS returns no context or passthrough mode.
- 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 source-of-truth 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 personal Memory Passport conflicts may be returned to the user as a clarification. Each conflict has one resolution path.
Memory Passport
Memory Passport is for consent-based memory shared across independent agents or applications. The user approves an agent and chooses allowed categories and access level. Universal API calls then require both the agent’s secret API key and the consenting user’s UUI token. An organisation connection proves account ownership; it does not replace an agent permission grant.
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