Domain Schemas

How MemoryOS separates the General Engine from domain-specific engines such as EdTech and Support.

One SDK. Multiple backend behaviors.

Every tenant starts on the General Engine. Enable a domain schema when your product needs industry-specific memory — the SDK calls don’t change.

mem.add(...)  →  same call, different backend extraction
mem.get(...)  →  same call, domain-aware context returned

Which engine to use

Product type	Use
Chatbot, assistant, copilot, coding agent, SaaS personalization	General Engine
Tutoring, exam prep, learning app, student coach	EdTech Schema
Customer support bot, support copilot, agent-assist	Support Schema
HR, healthcare, agriculture, or other future domains	General Engine today

Available domains

Domain	Status	What it adds
General Engine	Available	Facts, preferences, goals, procedures, relationships, expertise
EdTech Schema	Available	Student profile, grade, curriculum, weak/strong topics, exam context, forgetting stages
Support Schema	Available	Customer support profile, open issue, issue history, support type, sentiment, escalation risk
HR Tech	Coming soon	—
HealthTech	Coming soon	—
AgriTech	Planned	—

Enabling a domain

From the workspace dashboard: Settings → Domain Schema, or via API:

PATCH /v1/tenant/domain-schema
Authorization: ApiKey mem_...
Content-Type: application/json

{ "domain_schema": "edtech" }

{ "domain_schema": "support" }

{ "domain_schema": null }

The last option returns to the General Engine.

What changes on add()

General tenant
  quality gate → extraction → conflict resolution → memories + vectors

EdTech tenant
  quality gate → extraction → conflict resolution → memories + vectors
  → EdTech overlay → edtech_memories

Support tenant
  quality gate → extraction → conflict resolution → memories + vectors
  → Support overlay → support_memories

Your app still sends the same messages and external_user_id.

What changes on get()

General tenant
  retrieval → ContextBuilder → generic system_prompt_addition

Domain tenant
  retrieval → ContextBuilder → domain retriever → domain-aware system_prompt_addition

Your model-call path stays the same:

result = mem.get(query=current_task, external_user_id=external_user_id)

system_prompt = BASE_PROMPT
if result.has_context:
    system_prompt = f"{system_prompt}\n\n{result.system_prompt_addition}"

Dashboard vs. model-call APIs

Use get() for model calls. Use domain profile and tenant endpoints for dashboards.

Need	API
Prompt context for an AI response	POST /v1/memories/retrieve
Store conversation memory	POST /v1/memories/add
Student profile UI	GET /v1/memories/edtech-profile
Support customer dashboard	GET /v1/tenant/customers
Tenant domain settings	GET /v1/tenant/domain-schema

Related pages

• General Engine
• Support Domain
• Cookbook: choosing an engine
• EdTech tutor cookbook
• Support agent cookbook