Skip to main content
Every memory in Memory Crystal is filed into a store and tagged with a category. Stores organize memories by cognitive type — what kind of knowledge they represent. Categories tag the specific nature of the content within a store. Together they let the Context Engine weight and route recall precisely.

​
Five memory stores

StorePurposeExample
sensoryRaw observations and signals”Andy sounds frustrated about the deploy”
episodicEvents and experiences”We shipped v2 on March 15”
semanticFacts and knowledge”The API uses Convex for the backend”
proceduralSilent patterns, runbooks, and how-to memory”Deploy with npm run convex:deploy”
prospectivePlans and future intentions”Need to add billing webhooks next sprint”
Sensory memories capture raw observations — things noticed in the moment that might not be facts yet. Tone, emotional signals, and ambient context land here. These memories have shorter relevance windows and are weighted lower for factual recall.
Episodic memories record events that happened. Deployments, decisions made, meetings held, milestones reached — anything that is a specific occurrence with a time and place. The temporal recall pipeline draws heavily on this store.
Semantic memories hold stable facts and knowledge. Technical details, architecture choices, team structure, product behavior — things that are true and likely to remain true. This is the most frequently searched store for factual questions.
Procedural memories store how to do things: commands, workflows, runbooks, and repeatable processes. When the Context Engine selects Workflow recall mode, it searches this store with elevated weight. Approved skills can be promoted on top of procedural memory, but procedurals remain the quiet execution layer by default.
Prospective memories hold plans and future intentions. Things you want to do, tasks to revisit, features planned for later. The Context Engine surfaces these when the conversation moves toward planning or next steps.

​
Nine memory categories

Within stores, memories are tagged with a category that describes the specific type of content.
CategoryWhat it represents
decisionA choice that was made and why
lessonSomething learned from experience
personA person — who they are, their role, ownership areas
ruleA constraint or policy to follow
eventSomething that happened
factA stable piece of knowledge
goalAn objective or desired outcome
workflowA repeatable process
conversationConversational context and continuity
Categories make recall precise. When you ask crystal_why_did_we, the engine prioritizes decision and lesson memories. When you ask crystal_who_owns, it focuses on person memories. You don’t need to specify the category — the right tool or recall mode brings the right category to the front automatically.

​
Automatic categorization

When an extraction pass runs after a conversation turn, the LLM assigns both a store and a category to each extracted memory. You don’t tag memories yourself — categorization is inferred from the content. For example:
  • “We decided to use Convex because of its real-time subscriptions” → semantic store, decision category
  • “Deploy with npm run convex:deploy from the repo root” → procedural store, workflow category
  • “Sarah owns the billing module” → semantic store, person category
  • “Never push directly to main” → procedural store, rule category
If you store a memory manually using crystal_remember, you can specify the store and category explicitly — or leave them blank and let Memory Crystal infer them from the content.
You can update a memory’s store or category at any time using crystal_edit. This is useful if an automatic classification doesn’t match how you want the memory to be recalled.