Corrected on 11 October 2026. Earlier versions of this article named layers 6 and 7 "Prospective" and "Long-Term",
described sleep replay and Hebbian learning as things ZenBrain does on its own, and had long-term memories fade over time.
Measured against the code of v0.5.1, layers 6 and 7 are Core Memory and Cross-Context Memory, replay and Hebbian learning
are library functions the coordinator does not call, and only working memory decays. The earlier sentence that none of four
named systems implements sleep consolidation is withdrawn: Letta Code does it as "dreaming". This version follows the code;
the reference is the README table
What runs on its own, and what you call yourself.
TL;DR
- ZenBrain organises agent memory in seven layers, from working memory to cross-context memory, instead of one flat vector store. Each layer holds a different kind of memory and is stored and searched in its own way.
- The MemoryCoordinator in
@zensation/coreroutes what you store to a layer, searches four layers on recall, promotes emotionally weighted episodes to facts and gives every fact an FSRS review schedule. -
Sleep replay, Hebbian learning and Bayesian confidence are functions in
@zensation/algorithms. The coordinator does not call them; you wire them in where you want them. - Open source under Apache 2.0, written in TypeScript. The library makes no network calls of its own; memory lives in SQLite or PostgreSQL that you operate.
Why one flat store leaves questions open
Most agent memory starts as a flat vector store: embed the text, store the vector, retrieve by cosine similarity. That works for finding similar sentences. It does not say which memory is the current task and which is background, whether a sentence records something that happened or something that is true, or which few facts belong in every conversation.
Cognitive psychology separates these kinds of memory. Baddeley (1974) described working memory as a small, active store; Tulving (1972) separated episodic memory, what happened, from semantic memory, what is known; procedural memory is knowing how rather than knowing that. ZenBrain takes this separation as its design model. The rest of this article describes what the code does with it.
The seven layers
Layer 1: Working Memory
Purpose: active task focus.
Working memory holds seven slots by default, after Baddeley's model and the "7 ± 2" span. When a new item arrives and the slots are full, the least relevant slot is evicted. Relevance decays exponentially with age, and slots that fall below a minimum disappear. This layer lives in process memory and needs no storage adapter. Everything you store through the coordinator also lands here for immediate access.
Layer 2: Short-Term / Session Memory
Purpose: the context of one conversation.
Short-term memory keeps the interactions of the current session in a sliding window, 50 by default. Starting a new session clears it. The coordinator hands it to the language model as a list of messages.
Layer 3: Episodic Memory
Purpose: concrete experiences: "Last Tuesday, when we discussed the API redesign …"
Each episode is stored with its time, its context and an emotional weight. Episodes can be retrieved by recency, by context and by similarity to a query: by vector similarity with an embedding provider on PostgreSQL with pgvector, lexically otherwise.
Layer 4: Long-Term Semantic Memory
Purpose: facts: "PostgreSQL supports pgvector for embeddings."
Facts carry a confidence score, a source and an FSRS review schedule. This is where episodes end up when consolidation distils them into general knowledge.
Layer 5: Procedural Memory
Purpose: how to do something.
A procedure stores its trigger, its steps, the tools it uses, its expected outcome and a success rate. Each piece of feedback updates the success rate as a running average. With an embedding provider, recall ranks procedures by similarity to the query; without one, it ranks them lexically and weights each by its success rate.
Layer 6: Core Memory
Purpose: a few pinned facts that belong in every conversation.
Core memory follows the pattern Letta (formerly MemGPT) introduced: pinned, editable blocks that never decay. By default every recall includes all core blocks, like a profile; with core: 'matching' only the blocks that share a word with the query come back. The coordinator routes content stored with a confidence above 0.9 here.
Layer 7: Cross-Context Memory
Purpose: connecting knowledge across domains such as work, personal and learning.
This layer is meant to find the same entity in different contexts by name similarity and to propose merges. In v0.5.1 it is a building block rather than a wired-in layer: recall does not use it, and the comparison does not yet keep the contexts apart.
What runs on its own, and what you call yourself
Inside store() and consolidate(), the coordinator does four things on its own. It routes: step-by-step content becomes a procedure, content with an emotional weight above 0.5 becomes an episode, content with a confidence above 0.9 becomes a core block, anything else becomes a fact. It tags every stored item with an emotional weight. It gives every new fact an FSRS schedule. And it decays working memory.
Everything else is a library of tested functions in @zensation/algorithms: twenty modules, ten core and ten advanced. Several mechanisms this article names live there alone, and the sections below say which.
Consolidation, in the coordinator and in the library
In neuroscience, sleep consolidation is the process in which the hippocampus replays recent experiences during rest, strengthening important memories and pruning weak connections (Stickgold & Walker, 2013). Two pieces of ZenBrain carry the idea.
In the coordinator, consolidate() looks at the 100 most recent episodes. Each one with an emotional weight above 0.5 that has not been promoted before becomes a semantic fact, distilled by a language model if you configure one and verbatim otherwise. The episode is marked so that a later pass leaves it alone, and working memory decays in the same pass. Nothing in long-term memory is deleted.
In the library, the sleep consolidation module simulates replay: selectForReplay() prioritises emotional and recently accessed memories, simulateReplay() raises their stability, and pruneWeakConnections() removes weak Hebbian edges. The coordinator does not run this replay. You call it on memories you manage yourself.
Idle-time consolidation is pursued elsewhere too, for example as "dreaming" in Letta Code.
Spaced repetition with FSRS
FSRS, the Free Spaced Repetition Scheduler, comes from flashcard software such as Anki. It computes the next review from a memory's stability, its difficulty and the time elapsed, and expresses the predicted chance of recall as retrievability between 0 and 1.
In @zensation/core every fact gets an FSRS schedule when it is stored. getReviewQueue() lists the facts that are due; when your application reports a review with recordReview(), FSRS sets the next one. Recall does not rank results by retrievability.
Hebbian learning
"Neurons that fire together wire together" (Hebb, 1949). The library strengthens the edge between two memories each time they are activated together, lets unused edges weaken, and normalises the weights so that no single connection runs away. @zensation/core keeps no knowledge graph, so you apply these functions to a graph of your own.
The numbers, as of v0.5.1 (11 October 2026)
- 822 tests green in CI, on Node 22, 24 and 26 and against PostgreSQL with pgvector
-
20 algorithm modules in
@zensation/algorithms, 10 core and 10 advanced, with no runtime dependencies -
7 layer classes in
@zensation/core; recall searches episodic, semantic, procedural and core memory, working memory on request - No network calls of the library's own; memory lives in SQLite or PostgreSQL that you operate
Try it
The packages require Node.js 22 or newer:
npm install @zensation/core @zensation/algorithms
GitHub: github.com/zensation-ai/zenbrain · Playground: the live playground runs the published algorithm library in your browser, no install required.
Top comments (0)