Search Is Memory's Write Path

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.

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.

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

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 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.

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).

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.

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.

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.

"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.

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.

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.

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.

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 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.

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.

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."

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.

"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.

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.