Episodic, Semantic, and Procedural Stores

The route

4 steps to Done

1. 01

   Define the three schemas

   Each memory kind answers a different question - schema follows.

   Preview prompt + verify gate ▾ Hide ▴

   Define schemas for the three stores. EPISODIC (what happened): {session_id, date, task, outcome, notable_events[], artifacts_touched[]} - compact narrative records of sessions and incidents. SEMANTIC (what is true): {statement, topic, provenance, confidence, source_episodes[]} - atomic declarative facts. PROCEDURAL (how to do): {goal, preconditions[], steps[], verification, failure_modes[], last_validated, source_episodes[]} - executable recipes. Write two real examples per store from my project history, including one entry that must be SPLIT (a session story containing both a new fact and a new recipe) to demonstrate the routing discipline.

   • ✓ Schemas capture type-distinct fields
   • ✓ Procedures include verification and failure modes
   • ✓ The split example shows one input becoming multiple typed entries
2. 02

   Build classification and routing

   The sorting hat for memories.

   Preview prompt + verify gate ▾ Hide ▴

   Implement the write-time classifier. Given a candidate memory, classify into episodic/semantic/procedural (a compact LLM classification prompt with the three question-test definitions and few-shot examples works well); content spanning types is split into multiple typed entries with cross-links; each entry is then validated against its store's schema (procedures missing verification are bounced back for completion). Route writes to per-store files or collections. Test with 12 labeled candidates covering clear cases, spanning cases, and junk that should be rejected entirely - require 12/12 correct routing.

   • ✓ Question-test definitions drive classification
   • ✓ Spanning content splits with links
   • ✓ Schema validation bounces incomplete entries
3. 03

   Implement type-appropriate recall

   Ask each store the question it exists to answer.

   Preview prompt + verify gate ▾ Hide ▴

   Build recall per store. EPISODIC: query by time range, task keyword, or artifact ('what happened last time we touched the payment code?') - results ordered by recency. SEMANTIC: query by topic with the hybrid recall stack - results are statements with confidence. PROCEDURAL: query by goal ('deploy to staging') - return the single best procedure, preferring recently-validated ones, rendered as its steps. Then build the routing layer: the agent's memory_search tool classifies the query intent (what happened / what is true / how do I) and targets the right store, with a combined mode as fallback. Test the three canonical queries and verify each returns its correct type.

   • ✓ Each store has fit-for-purpose query mechanics
   • ✓ Query intent routing works on the canonical trio
   • ✓ Procedures render as actionable steps
4. 04

   Wire lifecycles and the failure-feedback loop

   The payoff link: episodes correcting procedures.

   Preview prompt + verify gate ▾ Hide ▴

   Implement per-store lifecycles and the feedback loop. Lifecycles: episodes compress after 30 days (keep task, outcome, links; drop detail) and archive after 90; facts follow confirmation/decay rules; procedures gain last_validated on observed success. Feedback loop: when a session episode records a procedure failing, flag that procedure - next use requires caution, and a diagnosed cause updates its steps or failure_modes with the episode cited. Test end-to-end: record an episode where the deploy recipe failed on a new precondition, verify the procedure gets flagged and updated with the episode link, and confirm the next 'how do I deploy' returns the corrected version.

   • ✓ Episode compression preserves links
   • ✓ Procedure failure flag works
   • ✓ Corrected procedure cites its source episode

Research-backed

Sources behind this flow