A flat buffer cannot tell what HAPPENED from what is TRUE from how to DO a task. Feed in four turns and watch the write router classify each by KIND of knowledge and drop it in the matching store. Each store has its own read path.
The world: the same refund desk. User Dana, order ORD-3300, a $200.00 order returned AFTER the 30-day window, a 10% restocking fee, so the policy-correct refund is $180.00.
The four kinds: working (now), semantic (true), episodic (happened), procedural (how-to). Episodic formalizes Part 5's reflection buffer; procedural holds Part 5's promoted rule.
Press Route next turn. The router reads each turn, decides which KIND of knowledge it is, and sends it to one of the four stores. Offline the router is a transparent rule policy; a real system swaps the body for one classification call.
The four stores, filling live
workingwhat we are doing now
volatile scratchpad. CORE block task_state.
semanticwhat is TRUE
durable facts about the user and the world. CORE block user_profile.
episodicwhat HAPPENED
an event log. Formalizes Part 5's flat reflection buffer.
proceduralhow to DO a task
learned rules. Holds Part 5's promoted reflection.
Memory as an action: the agent rewrites its own core blocks
Every tool through Part 5 was read-only. Here memory_append and memory_replace are first-class tools, declared with the Part 1 contract (typed schema, validated before they fire) over the labeled CORE blocks. The controller calls them in-loop to edit its own persistent memory. This is MemGPT/Letta by hand.
Each call passes through validate() first (Part 1's gate). A valid call edits a CORE block; an invalid one returns an error AS an observation (Part 2), it does not crash. Watch user_profile change from "prefers email" to "prefers phone".
The two CORE blocks (always in context)
user_profileCORE
task_stateCORE
The tool calls, validated then fired
Placement (core / recall / archival), and one reply from all four memories
Orthogonal to the four KINDS is an OS-style sketch by ACCESS PATTERN: what is always in context, what is paged in, what is searched. The archival read reuses RAG retrieval as a black-box tool. We do not re-derive embeddings, similarity, or vector databases here. Vector search is demoted to one read tool.
core · always in context
The labeled blocks user_profile, task_state (the ones the agent edits above).
recall · recent, paged in
The last episodic event: User opened a return request for ORD-3300 earlier today.
archival · large, searched
A big store read only through a search tool.
vector_search('restocking fee returns after the window')
↳ 'Returns after the 30-day window are still refundable, minus a 10% restocking fee.' (score=0.63)
black-box RAG, not re-derived here
✓ Composed reply, reading all four memories at once
semanticworkingproceduralarchivalepisodic
Hi Dana, for ORD-3300 returned after the 30-day window your refund is $180.00 (the 10% restocking fee applies). We will call you by phone.
What the four stores buy you: a flat list buries facts under events and reads a learned rule like a one-off note. Typed stores plus a write router keep them apart, each with its own read path; memory_append and memory_replace make memory an ACTION the agent takes, not just state it reads; and archival is one black-box retrieval call (RAG demoted to a tool), not a vector database rebuilt here.
working
semantic / profile
episodic
procedural
validation error