Search Is Memory's Write Path

Retrieval and memory are sold as two capabilities. A code search tool indexes a repository and answers questions about it. A memory tool stores notes and hands them back later. Separate documentation pages, separate benchmarks, separate pricing lines.

They are not two systems. They are two phases of one system, and the boundary between the phases is time, not architecture: the first search is the write. Every repeat of that search is the read.

Watch what actually happens when an agent searches a codebase for where a workspace lock gets released. Three to six tool calls later it holds a durable fact about that repository: which module owns the release, under what condition, and why the caller-side release path the documentation mentions no longer applies. Producing that fact pushed several thousand tokens of file content through the context window. If the fact disappears when the conversation ends, the same three to six calls get paid again next week, and again the week after. The search subsystem handled this fact at one moment in its life. The memory subsystem exists for every moment after that. The only reason they look like separate products is that they have separate user interfaces.

This essay makes the unification precise, borrows the mechanism from cognitive science, where it has been formalized and tested for nearly forty years, and then isolates the requirement that makes agent-side memoization strictly harder than the human process it is modeled on. That requirement inverts the design goal most memory products start from. Getting it wrong produces a system worse than no memory at all.

Note on this text version. The canonical page at swapnanilsaha.com includes two interactive demos (a race simulator and a gate-versus-additive walkthrough). They are summarized in place below as static notes.

Part 01 · The Mechanism Already Has a Name

What Instance Theory Says About Agent Memory

In 1988, the cognitive scientist Gordon Logan published a theory of how people get fast at things. It is called the instance theory of automatization, and it describes skilled performance without invoking any special fast mode that switches on after training. It earns its place in an engineering post by describing this mechanism exactly, failure modes included, and by yielding predictions you can test against agent behavior.

A programmer already knows this mechanism under a different name. Memoize a function and the first call computes the answer the slow way; later calls with the same input return the cached value instantly. Nobody redesigns the function to be faster. The speedup comes entirely from keeping the old answer around. An agent with no memory is that function with the cache disabled, re-running the full computation every session, and the expensive computation is not a Fibonacci number. It is understanding a codebase.

The theory runs as follows. When you first meet a task, you solve it by running an algorithm: a general procedure that works but costs effort. Each time you solve it, the solution is separately encoded as a trace, an instance. On every subsequent encounter, two processes start simultaneously and race: the algorithm runs again from scratch, and memory retrieval attempts to surface a stored instance. Whichever finishes first produces the answer. Early on the algorithm usually wins, because few instances exist to retrieve. As they accumulate, retrieval finishes earlier and begins winning more often. Automaticity is not a mode. It is the observable consequence of retrieval having won the race often enough to dominate.

The race formulation is load-bearing, so pin it to sources. Logan's paper presents action selection as a competition between an algorithmic process and a memory retrieval process, decided by whichever finishes first; open-access papers describing the theory state it in exactly those terms, and one co-authored by Logan reaffirms it (Best et al., 2016). The paper's abstract carries the rest of what matters here: automatization is the acquisition of a domain-specific knowledge base of separate representations, one stored per exposure; processing counts as automatic when it relies on retrieving those stored instances; and retrieval pays off after practice within a consistent environment, a condition whose weight grows through this essay until it becomes the whole problem.

The mathematics of getting faster. Give the algorithmic route a finishing-time distribution that never changes. Give each stored instance its own finishing time drawn from a retrieval distribution that also never changes. Retrieval finishes at the minimum of n independent draws, one per stored instance:

T_retrieve(n) = min(R1, R2, ..., Rn)

A minimum can only move earlier as n grows, and it moves earlier fast: with heavy-tailed finishing times, the fastest of twenty draws routinely beats the fastest of five by a wide margin. Logan showed that this produces the classic power-law shape of practice curves, response time falling as a power of the number of exposures, with variability shrinking on the same schedule. Nothing in either distribution improved. Only the count did.

You can feel this mechanism directly in the race simulator on the canonical page. The algorithmic route keeps its exact speed across every trial. All that changes is how many past solutions sit in memory.

(Demo note: the algorithm draws one finishing time from a fixed skewed distribution with median 1000 ms; each stored instance contributes an independent draw with median 2100 ms and wider spread; retrieval finishes at the fastest of them. Neither distribution improves with practice. Only the count changes.)

At one stored instance, retrieval almost never contributes. Around ten to fifteen, the two routes become competitive. Past thirty, the algorithmic route is mostly idle overhead. Every practitioner who has watched themselves debug a familiar system recognizes the trajectory: the first investigation is slow and deliberate, and somewhere along the way the answers simply arrive.

Four Properties That Transfer to Agent Memory

Four features of the model carry over to agent tooling, and each one settles an argument that agent memory products are currently having with themselves.

The Race Is the Architecture

Retrieval does not replace the algorithm and does not gate it. Both start. In the theory this is the core structural claim; in engineering it is also the only safe shape. An agent that must consult memory before it is permitted to search has acquired a new single point of failure and a new class of silent error. An agent that receives a remembered answer alongside a fresh search strictly has more information than before, and no new way to fail. Racing is both what the theory describes and what engineering would choose anyway. When a descriptive model and a design principle point the same way, treat the coincidence with suspicion; Part 04 shows why this one survives scrutiny.

Speedup Comes From Accumulation, Never From a Better Algorithm

In the instance model the algorithm never gets faster, not at any point on the learning curve. The entire observed speedup comes from the growing population of retrievable instances pulling the retrieval minimum downward. This maps onto agent tooling with uncomfortable directness, and it is the part most retrieval work ignores. You can spend a year improving embeddings on conceptual queries, which is worth doing on its own merits, and you will have tuned the side of the race that is structurally supposed to lose. The compounding term lives on the other side of the bracket.

Practice Is Environment-Scoped, and the Environment Must Be Consistent

Instance retrieval helps because the world stays put. The word you learned to read is still that word. The route you learned still goes there. Under inconsistent mapping, where the correct response to the same situation changes between encounters, the benefit does not shrink. It goes away, and retrieval turns into an active source of error. Hold onto this one. It is where agents and humans come apart, and it is the entire subject of Part 03.

Retrieval Starts on Contact, Not by Decision

In the theory, both routes begin when the task does. There is no checkpoint where the system weighs whether consulting memory is worth the trouble; if retrieval waited for a decision, it would forfeit every race before starting, and the theory's speedup predictions would reduce to the algorithm's timing alone. That is a design specification, and it is the one most agent memory products fail. If the model has to decide to call a memory tool, retrieval is not racing, it is applying for permission to race, and it competes against a fast trained prior carrying no such overhead. Anyone who has watched an agent ignore a memory tool mentioned twice in its system prompt has seen the prediction play out.

The object of interest is not the store. Most agent memory systems are designed as a store with a retrieval endpoint attached. Instance theory says the interesting object is the race, and the race has an entry condition: retrieval must start without being asked. A memory system the model has to choose to consult is not losing the race. It is standing next to the track.

Memory on a Budget: The Economic View

Work adjacent to Logan's puts an economic frame on the same territory. The rational-analysis program in cognitive science treats memory as an adaptive system whose accessibility tracks need probability: the likelihood that a piece of information will be needed again, forecast from the statistics of its past use (Anderson & Milson, 1989). Gershman's open-access overview describes the move as explaining the structure of memory in terms of beliefs about the future, borrowing a library's logic: books that circulate stay reachable, books that do not drift out of reach (Gershman, 2017).

Read as engineering requirements, that is memoization with a budget. Retaining a computed result is justified exactly when the expected cost of recomputing it exceeds the cost of storing and serving it. Which results to retain is therefore an allocation decision, not a passive byproduct of activity. The metric that disciplines the decision is computation avoided.

That is the correct frame for agent tooling, and it is not the frame agent memory products currently use. They optimize storage efficiency and recall quality. Few of them optimize, or even publish, avoided recomputation. The rest of this essay is about what happens when you take that metric seriously: what it wastes today (Part 02), what makes it dangerous (Part 03), what architecture contains the danger (Part 04), and which half of the problem remains genuinely open (Part 05).

Part 02 · Why Agents Re-Derive Everything

Zero Instances Every Session

Every session an agent begins is a session in which it holds zero instances. It re-enters a codebase where it has already solved forty problems, finds the retrieval side of the race empty, and runs the algorithm from scratch. Not because the algorithm is poor. Because nothing accumulated.

The observable symptoms are mundane and universal. Agents grep for the same symbol repeatedly within a day. They re-read the same files across sessions. They rediscover the same build quirk, the same test invocation, the same reason a migration was structured oddly. Capable models do this too, and they do it precisely because the trained prior for locate something in a repository is strong, fast, and extremely well practiced. That algorithm wins the race by default because nothing is competing.

The easy misdiagnosis blames the context window, and the distinction decides whether more capacity can fix anything. A larger window makes the current session's algorithm cheaper to run. It does nothing whatsoever for accumulation, because the accumulation was never written anywhere that outlives the window. The proof fits inside a single session: compact the context, and the exact file paths, signatures, and line numbers the agent spent the morning establishing do not survive the summary. Those facts were fully present in the window. Capacity was not the binding constraint. Persistence was.

Capacity and persistence are different budgets. Any argument of the form "context windows keep growing, so this problem fades" quietly assumes the two budgets are the same. They buy different things. Window capacity lowers the cost of the current derivation. Persistence eliminates future derivations. One is a discount; the other is the product.

The Arithmetic of Wasted Derivation

Intuition undersells the waste, so put numbers on it. What follows is illustrative arithmetic, not measurement: the shapes are typical, and the point survives any reasonable rescaling.

Take a moderately complex discovery: establishing how a subsystem's lifecycle works well enough to modify it safely. Call it five tool calls, one broad search, two targeted ones, two file reads, with roughly eight thousand tokens of file content passing through context to produce perhaps forty tokens of durable conclusion: the lock is released on scope exit in the resolver, not by the caller; the caller-side release shown in the docs predates the refactor.

Two numbers to sit with.

Compression, about 200 to 1. Eight thousand tokens in, forty tokens of durable conclusion out. The conclusion is tiny; the derivation is enormous. Any system that logs the tool stream has archived the expensive part and discarded the valuable one.

Recurrence, linear in project lifetime. If that conclusion is needed in ten future sessions: naive cost is fifty tool calls and eighty thousand tokens of re-derivation. Memoized cost is the original five calls plus ten cheap injections. The saving is not a constant factor on one query. It grows with how long the project lives and how often anyone works on it, which is why it compounds while per-query improvements do not.

This is also why the metric retrieval systems usually report measures the wrong thing. Per-query relevance scores the algorithm side of the race, the side that is structurally supposed to lose. The number that matters here is the re-derivation rate: the fraction of an agent's discovery work that re-establishes a fact already established, by the same agent or another agent, in the same workspace. It compounds across sessions, and a stateless search tool cannot move it at any level of ranking quality.

Three Lanes of Code Search, and Which One to Concede

"Search" bundles three different problems, and running them together is why the search-versus-memory debate keeps stalling. Separated, the allocation becomes obvious.

Concede lane one without a fight. It is not winnable, and it does not need to be won. Once conceded, the reframing lands: search stops being a scoreboard against grep and becomes an engine, whose job is to produce, on first encounter, a fact worth writing down. Lane two matters because structural facts are exactly the ones that are expensive to re-derive and cheap to store. Lane three matters because a conceptual question is the likeliest to be asked again in different words, which is precisely the situation where a stored instance wins a race that a fresh similarity search would lose.

From scoreboard to engine. Judging semantic code search by head-to-head relevance against grep asks the wrong question twice over: it flatters the lane grep already owns, and it ignores the only output that compounds, namely the facts captured on first discovery. The engine question is narrower and harder: did the first pass produce anything a later session should never have to re-derive?

Part 03 · The Requirement Cognition Does Not Have

Code Is an Unstable Environment

Here is where the borrowed model stops being sufficient, and agent memoization becomes its own problem rather than an application of an existing one.

Logan's consistency assumption does quiet, heavy work. Human environments hold still long enough for accumulated instances to stay applicable, and the experiments behind the theory manipulate exactly this: keep the mapping between situation and response stable and automaticity arrives; scramble it and the benefit vanishes. Code is not a stable environment. It is an environment whose explicit purpose is to be modified, by many people, continuously, in ways that invalidate recorded facts without any signal reaching whoever recorded them. A remembered fact about a codebase has a half-life measured in commits, not clock time, and commits do not arrive on a schedule.

That inverts the design objective. In the cognitive model, winning the race is the goal without qualification; faster retrieval is better retrieval. In a codebase, a stale instance winning the race is the worst outcome the system can produce. Worse than having no memory at all, and the reason is specific: a wrong answer delivered confidently and quickly displaces the correct algorithm that would otherwise have run. The agent stops searching at exactly the moment it most needed to search. With no memory, it pays five tool calls and receives the truth. With confidently wrong memory, it pays almost nothing and acts on a falsehood, and no point in the process announces the error.

The asymmetry that drives everything else. A missing note costs a re-derivation the agent was already paying daily. A silently wrong note corrupts work downstream of it, and the corruption surfaces far from its cause, attached to someone else's diff. Systems should be tuned asymmetrically in favor of the first failure. Most are tuned symmetrically, as if the two cost the same.

So the central design requirement for agent-side discovery memoization is not retrieval speed. It is this:

The stale instance must lose the race.

Every meaningful architectural decision that follows, in Parts 04 and 05, follows from that one sentence.

Why Semantic Caching Fails This Requirement

The obvious implementation of "remember past answers and serve them again" is a semantic cache: embed the incoming query, look for a near neighbor among past queries, serve the neighboring answer on a hit.

It fails on exactly the requirement above, and the failure is structural rather than tunable. Semantic similarity establishes that the current question resembles a previous question. It says nothing about whether the previous answer is still true. Those are unrelated axes. A query can be word-for-word identical to one asked last month and have a different correct answer today, and the cache has no channel through which it could ever discover that. Cosine distance between two questions is not evidence about the world the questions are about.

Caches get away with this in their home territory because of a property code does not have: a cached HTTP response has a live source of truth a miss can re-fetch cheaply, and its staleness is bounded by the resource's own change rate. A memoized discovery has no cheaper source to fall back on. Re-fetching means re-running the entire derivation, which is precisely the cost the memoization existed to avoid. Whatever detects staleness therefore has to be anchored to the artifact itself, not to the query that happened to surface it.

Five Shapes of Drift, and What Detects Each

Staleness is not one phenomenon. It is at least five, with different shapes and different detectors, and treating them as one problem is why so many systems reach for a timestamp, which detects none of them.

Three things fall out of that table.

Content hashing is cheap and covers the common case. Store the hash of the anchored region when the note is written; compare on read; when they differ, the note neither disappears nor wins. It surfaces with visibly reduced confidence and its anchor flagged, and the model arbitrates whether to re-verify. That is the correct behavior because it preserves the additive property developed in Part 04: a possibly-stale note remains evidence, just evidence wearing a caveat.

# episode · recorded 14 August 2026
claim:             the workspace lock releases on scope exit inside resolver.acquire()
anchor:            src/workspace/resolver.py, lines 88-141
content_hash:      9f3c1eab   # recomputed at read time; mismatch = surface with caveat
verification_hint: pytest tests/workspace/test_lock.py -k scope_exit
provenance:        distilled at session end, 14 August 2026, from a five-call derivation

Semantic drift has no cheap detector, and pretending otherwise is where these systems acquire their worst failure mode. The right response sidesteps detection entirely: make the note's claim checkable rather than attempting to detect its falsity. A note that carries a one-command verification hint converts an undetectable staleness problem into a cheap confirmation the agent can run when stakes justify it. Detection was the wrong target; confirmability is achievable.

None of these detectors is a clock. Elapsed time is evidence about none of the five rows. A year-old note on why a migration was structured a certain way can be the most valuable object in the store today; an hour-old note can already be wrong because someone pushed in between. Age reasonably informs ranking. It must never decide validity, because age does not measure validity. It measures the passage of time.

The timestamp trap. A TTL is the default staleness mechanism in most caching folklore, and importing it here imports exactly the wrong physics. Expiry by age deletes the note most likely to be both true and expensive to re-derive, the old one about stable things, while blessing the recent note about a moving target purely for being recent. Age ranks; anchors decide.

The invalidation signal must be deterministic. There is a tempting shortcut: let the model judge whether its own memories are stale.

Judging staleness competently requires looking at the current state of the code, which means running the algorithm, which is the exact cost the memoization existed to avoid. A model asked to assess a note's freshness either does the work, in which case the memory saved nothing, or guesses, in which case the guard is decorative. Hashes, symbol resolution, and explicit revocation records are deterministic, cheap, and produce their signal before the expensive path starts. That is what qualifies them as race conditions rather than after-the-fact audits.

Part 04 · The Architecture: Additive, Never Authoritative

The Gate Is the Wrong Shape

If the stale instance must lose the race, the tempting implementation is a gate: consult memory first, and on a hit, skip the search. That is a cache, and it is the wrong shape for this problem three times over.

A gate converts every staleness failure into an uncorrectable wrong answer, because the fresh search that would have exposed it never runs. It converts every memory-layer outage into an agent behavior change, which means the memory system now sits on the critical path of tasks it adds nothing to. And it introduces a judgment call, is this hit good enough to skip the search, that some threshold or classifier must make, invisibly, in both directions of error.

The correct shape is additive. The agent searches natively, with the fast trained prior that wins the early races anyway. The memory layer neither intercepts nor reroutes the query, and it never gates it. It injects remembered conclusions alongside, carrying provenance and staleness state, and the model arbitrates.

This buys a property that deserves its own name: the system is safe under total failure. Empty memory, wrong memory, stale memory, daemon down, index corrupted, and the agent degrades to precisely the behavior it would have had without any of it. There is no path on which the memory layer makes the agent worse at a task it could otherwise complete. That property is difficult to obtain from a caching architecture and free from an additive one, and it buys more than the marginal latency a gate would have saved.

(Demo note: the canonical page includes a walkthrough of four outcomes from the same stale note. Gated and still true: correct answer at lowest cost. Gated and stale: the agent acts on the falsehood and no step in the session could flag it; the error surfaces later, far from its cause. Additive and still true: fresh evidence confirms the note at the cost of one ordinary search. Additive and stale: the conflict is visible on the page, fresh evidence wins arbitration, and the note is flagged for revocation with the conflicting observation attached.)

The Corollary: No Query Classification

The additive invariant rules out something subtler, and this is a rule to hold absolutely rather than mostly.

Any logic that inspects an incoming query, decides what kind of question it is, and routes accordingly is a heuristic layer that will be wrong on queries nobody anticipated. Its wrongness is structurally invisible: when the router sends a query down the wrong path, the correct path never executes and produces no evidence of its absence. You cannot debug what did not run. Worse, these layers accumulate. Each observed failure breeds another special case, each special case interacts with the previous ones, and the system slowly becomes a pile of conditionals whose collective behavior nobody can predict.

Injection beside the query needs no classification at all. It fires on similarity to captured episodes and on structural conditions: which file is about to be edited, which symbol is about to be touched, which command is about to run. The model does the judging. That division of labor is correct on the merits. Deterministic mechanisms handle detection and delivery, where they are exact; the model handles judgment, where it beats any rule.

This is not hypothetical machinery. The working-memory layer I ship in Vectr works exactly this way: notes carry trigger conditions such as path globs and lifecycle events including pre-edit and post-compaction, firing is deterministic, and nothing in the recall path depends on a classifier deciding what a query "really is."

Part 05 · Capture Is the Open Problem

Capture Is the Open Problem

Recall is the solved half. Given a store of anchored episodes, surfacing the relevant one at the right moment is well-trodden engineering: similarity thresholds, trigger conditions, and structural hooks are all understood.

Capture is genuinely open, and the reason is structural: the valuable artifact is not in the tool stream. When an agent runs four searches and two file reads and concludes that the lock releases on scope exit in the resolver, not by the caller, that conclusion exists only in the model's reasoning trace. The tool layer observed six calls and their raw outputs. Logging those captures the cost of the discovery in full detail and captures the discovery not at all. This is the two-hundred-to-one compression ratio from Part 02, seen from the write side.

Three capture paths exist, and they fail differently.

Most teams approximate the first path today with a hand-maintained instructions file that the harness loads into every session. It works until its contents drift, at which point it becomes a short, confident, never-invalidated stale instance: Part 03's worst outcome with a README's filename.

The third path is the most promising and the least explored, and precision about why it works matters. The trigger is deterministic even though the content is model-generated. The model is never asked to decide whether something deserves recording. It is asked, at a fixed point, what it learned. That is a far easier request to get reliable behavior from than an open-ended standing instruction to remember things as they come up.

Notice that this is the same architectural bet as the read side. Deterministic injection solves the discretionary-retrieval problem; deterministic distillation solves the discretionary-capture problem. Both replace the model must choose to engage the memory system with the memory system participates automatically and the model judges the content. A memory system whose value depends on the model electing to call it has not solved memory. It has relocated the problem into prompt engineering, where every user will re-solve it badly, individually, forever.

Part 06 · Objections and Consequences

Objections Worth Taking Seriously

"This is just caching with extra steps." The two differ on the property that defines each. A cache holds a convenience copy of a source of truth that still exists and can be re-fetched cheaply on a miss, which is why TTL is a sound default there. A memoized discovery is not a copy of anything. Re-fetching means re-running the whole derivation, which is the cost being avoided. Their failure modes are opposite as well: a cache is wrong when it is too old relative to a re-derivable truth; a memoized discovery is wrong when the artifact it was anchored to changed, which is not a function of age. The gate-versus-additive distinction follows from exactly this difference.

"Models will keep getting better at search, so this evaporates." Better search improves the algorithm side of the race. It does not touch accumulation. A model twice as good at searching still starts every session with zero instances and still re-derives the same facts, only faster. The gap this essay addresses is not a capability gap. It is a persistence gap, and capability improvements do not close persistence gaps.

"Larger context windows solve it." Covered in Part 02, and the compaction case is the clean refutation: facts fully present inside a window do not survive summarizing that window. If capacity were the constraint, that could not happen.

"The model will just ignore the injected note." Sometimes it will, and under the additive invariant that is acceptable, because ignoring the note leaves the agent exactly where it would have been. The objection is fatal to a gated design and survivable in an additive one, which is itself an argument for the additive design. Compliance with injected claims is also an empirical question to measure rather than assume, and the current answer is that it is not yet well characterized.

"Staleness makes the whole thing too dangerous." The strongest objection, and the reason Part 03 is the longest part of this essay. The answer is not that staleness is rare. It is that staleness must be detected deterministically and surfaced, never silently resolved in either direction. A note that surfaces with a visible caveat is strictly better than no note. A note that surfaces silently as fact is strictly worse than no note. The entire engineering discipline lies in making sure it is always the first kind.

What This Reframes

Three consequences follow from taking the unification seriously.

Search demotes from headline to engine. If the first search is a write, search quality matters because it determines what gets written, not because it wins a benchmark against native tooling. Conceding the literal lane is not a retreat. It is the correct allocation of ambition: the value was never in beating grep on the first lookup, it is in never paying for the second one.

The metric changes. Stop reporting only per-query relevance, which measures the side of the race the algorithm is supposed to lose. Report the re-derivation rate, and report it across sessions, because that is where the effect lives. A retrieval layer that halved re-derivations while losing every head-to-head relevance contest against grep would have done more for the people using it than the reverse.

Compounding is the moat, and it is the only one. A search tool's value is per-query and flat. A memoizing system's value grows with the number of distinct discoveries banked in a workspace, which grows with use. Two systems with identical retrieval quality diverge on that axis alone, and the divergence widens with every session. Nothing stateless can compete on it, at any level of ranking quality.

The framing to carry out of this essay: search is memory's write path. The first search is capture, every repeat is recall, and the entire hard part is one guarantee: when the code has moved, the remembered answer loses the race.

References

Claims attributed to the two Psychological Review papers below rest on their published abstracts and on open-access papers that describe them; both journal articles are behind a paywall, and nothing in this essay quotes them beyond what those sources support.

Instance Theory and Automaticity:

• Logan, G. D. (1988). Toward an instance theory of automatization. Psychological Review, 95(4), 492 to 527. doi:10.1037/0033-295X.95.4.492. Separate instances per exposure; automatic processing as reliance on retrieved instances; consistency requirement; power-function speedup.
• Best, M., Lawrence, N. S., Logan, G. D., McLaren, I. P. L., & Verbruggen, F. (2016). Should I stop or should I go? The role of associations and expectancies. Journal of Experimental Psychology: Human Perception and Performance, 42(1), 115 to 137. Open access. States the race between algorithmic and retrieval processes in Logan's theory, and the role of consistent mapping.

Memory as an Adaptive System:

• Anderson, J. R., & Milson, R. (1989). Human memory: An adaptive perspective. Psychological Review, 96(4), 703 to 719. doi:10.1037/0033-295X.96.4.703. The rational-analysis framing: accessibility tracking need probability.
• Gershman, S. J. (2017). Predicting the past, remembering the future. Current Opinion in Behavioral Sciences, 17, 7 to 13. Open access. Overview of need probability and memory as beliefs about the future.

Related reading on this site:

• The Agent Never Chooses to Remember: Memory as a Harness Property. The read half of this essay's argument: deterministic injection instead of asking the model to opt into its own memory.
• Agent Memory Expiry Is a State, Not a Delete. What staleness handling looks like when age ranks but never decides.
• What Actually Survives /compact in Claude Code: An Empirical Map. The measured version of Part 02's persistence argument.