Skip to main content
This guide explains how an education company uses MemoryOS with the EdTech domain schema. You still use the normal SDK.
The difference is tenant configuration. Once your tenant has the EdTech schema enabled, MemoryOS automatically adds structured student memory, tutoring context, and EdTech-aware conflict routing.

Step 1: Enable EdTech for the tenant

The recommended onboarding UX is:
That sets:
Your MemoryOS dashboard can expose this during workspace setup or later under settings. Backend endpoint:
Response:

Step 2: Store student conversations

Use the same add() method.
Internally, MemoryOS writes both:
  • generic memories for normal retrieval
  • structured EdTech profile data in edtech_memories
The structured profile can include:
  • grade level
  • board or curriculum
  • subjects
  • weak topics
  • strong topics
  • concept gaps
  • language preference
  • explanation style
  • exam name and date
  • forgetting stages

Step 3: Retrieve tutoring context

Use the same get() method before your model call.
For an EdTech tenant, system_prompt_addition can include domain-aware context such as:
Your application does not need to build this manually.

Step 4: Build a student dashboard

If your app needs structured data for UI, call the optional domain helper.
This is useful for:
  • teacher dashboards
  • student progress screens
  • exam readiness views
  • weak topic review queues
  • spaced repetition panels
For normal AI responses, get() is enough.

TypeScript

Conflict behavior

EdTech conflict routing is automatic after the domain is enabled. Examples: Tenant admins should not manually decide personal student facts. MemoryOS routes those to user-session clarification.

Cross-agent sharing

If a student uses multiple learning agents and grants consent, safe EdTech summaries can project into universal memory. Examples:
  • Student prefers Hinglish explanations
  • Student is preparing for JEE Main
  • Student is working on improving thermodynamics
Full structured EdTech state stays domain-local.

Best practices

  • Use stable external_user_id values, such as your internal student ID.
  • Call add() after meaningful tutoring conversations, not every tiny UI event.
  • Call get() immediately before your LLM call.
  • Use context_max_tokens to control prompt budget.
  • Use get_edtech_profile() only when building domain UI.
  • Let MemoryOS handle conflict routing instead of exposing “keep A / keep B” choices to teachers for personal student facts.