Retrieval check (from lesson 5, new setting). You’re debugging a flaky integration test. Three log lines around the failure are ambiguous — could be a timing issue, could be unrelated noise — but one stack frame clearly names a null pointer in a specific module. Lesson 5’s islands of certainty strategy said: don’t process left-to-right through uncertain data; find wherever some signal is confident, and grow the investigation outward from it in both directions, because a strong hypothesis anywhere constrains its noisy neighbors. Applying that here — what do you look at next, and why, rather than starting from the first ambiguous log line? Answer before reading on; the solution confirms it.
Encoding, retrieval, and the two ways to test yourself
Encoding: getting information into memory — turning something you perceive or study into a stored trace. In lesson 10’s terms, encoding is what creates a new declarative chunk in the first place.
Retrieval: getting information back out — reconstructing a stored trace when you need it. In lesson 10’s terms, retrieval is a chunk’s activation crossing a threshold and surfacing into working memory.
Recognition (“is this familiar?”) and recall (“what was it, with no cue?”) are the two modes retrieval can take. Recognition is reliably easier — the answer, or something close to it, is present to be judged; recall requires reconstructing it from nothing.
The testing effect (Roediger & Karpicke and a large replicated literature): the act of retrieving a memory — effortfully, even with some errors — strengthens that memory more than an equal amount of time spent passively re-reading the same material. Being tested isn’t just a way to measure learning; it’s a more effective way to produce it than the more comfortable alternative.
Last lesson’s math explains why, mechanically. Base-level activation sums a decay term over every past use of a chunk — B = ln(Σᵢ tᵢ^(−d)). A genuine retrieval attempt, one where you reconstruct the chunk under some effort rather than having it handed to you, is a use event: it adds a term to that sum, exactly like an additional time the chunk was accessed. Passive re-reading is closer to being handed the chunk pre-assembled — you’re re-encoding the content, but you haven’t necessarily routed through the same effortful retrieval pathway that a real recall attempt does, so it’s a weaker candidate for counting as one of those summed “uses” at all.
The puzzle
Two designs for an LLM agent’s long-running memory, across a multi-day task:
- Design R (recognition-heavy): every fact the agent has learned is appended to a persistent context window that’s never trimmed. Whenever the agent needs a fact, it’s already sitting there — a cheap lookup, no reconstruction required.
- Design C (recall-heavy): the agent’s context is periodically compacted — old material is stripped out and replaced with a short summary. To use a fact from earlier, the agent must actively reconstruct it (re-derive it, re-query a store, or regenerate it from the summary plus its own reasoning) rather than finding it verbatim in front of it.
Suppose both agents are tested the same way: after a long delay (or a full context reset), each is asked to reproduce a specific fact from early in the task, from scratch, with nothing relevant in its current context. Using this lesson’s mechanism (retrieval as a use-event that compounds, from lesson 15) and the recognition/recall distinction above, predict which design’s underlying “memory” — not its context window, but whatever persists past a reset — would more reliably reproduce the fact, and explain specifically why in terms of which design actually generated genuine recall-style use events along the way, versus which one only ever generated cheap recognition-style lookups.