glossary//memory-layer
memory layer
A memory layer is one store inside an agent's memory system, with its own shape, its own lookup method and its own lifetime, such as a conversation ledger, a digest table or an entity graph.
Agent memory is the capability. A memory layer is one piece of the machinery that supplies it. A working system normally runs several layers at once, each answering a different question. Asking whether a system has agent memory is a yes or no question. Asking what its memory layers are gets you a list, with a lifetime attached to each entry.
A layer is not automatically a graph. Entities and edges are one way to build a layer that answers what is true about the world. A layer that answers what happened works better as an append-only log or a table of short digests, looked up by recency and keyword, not by name. Treating layer and graph as synonyms leads to a timeline shoved into a structure built for traversal.
The layers in one real system
Memory is easy, retrieval is hard lists three layers and states the lifetime for each. A Conversation Ledger is the complete source of truth and keeps everything forever. Session Digests handle episodic recall over recent sessions. Memory Items hold durable facts and preferences until superseded.
Give the model the tools, not the context numbers a longer stack over the same ground. Layer 0 is the ledger, searched by keyword through FTS5. Layer 1 is digests. Layer 2 is topic threads. Layer 3 is the entity graph, an append-only JSONL file looked up by entity substring search or by walking from one entity to its neighbours. Layer 4 is the tool surface, a set of tools over JSON-RPC that the model calls to read and write every layer below. Only one of those five is a graph, and the differences between the other four are differences in lookup, not just in content.
Why the boundaries are load-bearing
One call, the real prerequisite shows what clean layer boundaries buy. Four boot-time reads collapsed into a single memory_context call because the four do not depend on each other. A topic thread, an entity record, a procedural note and a memory row are bounded, separate things with separate reads, which is what makes them safe to fire in parallel. You cannot bundle four queries that secretly share state.
The order of causation is worth keeping straight. The call-count reduction came second. The layer design that allowed it came first, and if the stores had been entangled, no amount of client-side cleverness would have collapsed those calls.