Retrieval: starting warm

Part 2 ended with a warning: a full reservoir you can't drink from. Suppose capture is solved - failures logged, decisions recorded, quirks registered, handover notes written at every session end. You've stopped the leak.

You have not yet created any value. Storage isn't the asset; reuse is. A captured learning that the next session never consults is a write-off with extra steps: you paid to store it and still paid to re-derive it. The difference between an archive and an asset is whether it changes what happens next.

This part is about making that happen - and why it doesn't happen on its own.

The retrieval problem is worse than the capture problem

When capture fails, at least the person doing the work knows something was learned. They just don't write it down. Retrieval fails for a worse reason:

The person who needs the knowledge doesn't know it exists.

You can't search for what you don't suspect is there. The developer about to spend two hours rediscovering the date-format quirk has no reason to look it up first - as far as they know, no one has ever hit this before. The unknown unknown is the default state of every new session, every new hire, every new agent run.

"We have a knowledge base, people should search it" fails the same way "people should document things" does. Search is pull, and pull requires knowing to ask. The overwhelming majority of avoidable re-derivation happens in sessions that never suspected there was anything to retrieve.

So the design rule mirrors Part 2's: just as capture must move to the point of creation, retrieval must move to the point of need - before the work starts, without being asked.

Warm starts as the default posture

The operating principle: no session starts cold. Before a session - human or agent - begins work on anything, it consults what's already known about that thing. Not as a lookup of last resort when stuck, but as a pre-flight check, the way you read a file before you edit it.

Concretely, three retrieval moments matter:

Session start: the context pack. When a session begins work in a given area - a project, a codebase, a client, a vault of knowledge - it gets handed a compact bootstrap: the standing constraints, the recent decisions and their rationale, the known quirks, the open threads, the last session's handover note. This is push, not pull. Nobody had to know what to ask for; the system knows what the area's accumulated knowledge is and serves the distilled front page of it. This single mechanism kills the largest class of cold starts.

Decision points: check before choosing. When the work reaches a fork - pick an approach, choose a vendor, design an integration - the question "have we been here before?" gets asked explicitly. The answer that matters most is often a dead end from Part 2: A was tried in January and failed because X. Thirty seconds of retrieval versus re-walking the path at full price.

Failure points: check before retrying. For agents especially: a tool call fails, and before the retry loop starts burning attempts, the knowledge base gets consulted. Is this endpoint known to rate-limit? Is this domain known to need the heavy path? Is this error shape documented? A stack that checks its own memory on failure converts past pain directly into present routing decisions.

What this looks like in practice

This is the point in the series where I'll name our own stack, because it's the reference implementation these ideas were worked out on. Two pieces:

Levirge Search is the acquisition layer - web search, fetching, stealth browsing for AI agents. It's where a lot of session knowledge gets created: which sources are good, which endpoints fail how, which domains need escalation. Some of that capture is ambient, as described in Part 2. The stealth registry records which domains need the expensive path the first time that path works, and every later request from any session on that instance routes correctly on the first attempt. Capture and retrieval collapsed into one mechanism, inside the infrastructure, invisible to you.

Brain is the persistence layer - a knowledge base built for agent memory. The retrieval postures above map onto how it's actually used: sessions boot with a context pack for the vault they're working in rather than starting from a blank prompt; searches are scoped to the project at hand rather than fired into an undifferentiated pile; retrieved entries carry timestamps and provenance so a session can judge whether a two-year-old learning still binds. And retrieval closes a loop back into capture: when a retrieved learning turns out right or wrong in practice, that feedback is itself recorded - which is how the corpus learns what was worth keeping.

The stack details are ours, but the architecture is general: an acquisition layer that self-captures what it learns, a persistence layer that pushes context at session start, and scoped, provenance-aware search for everything in between. Any team could assemble the same shape from different parts.

The economics: compounding, finally with a mechanism

Part 1 claimed knowledge has a replacement cost. Retrieval is where that claim starts paying out, because every warm start is a discount on the task:

• A session that begins with a context pack skips the re-orientation tax - the re-reading, re-asking, re-deriving that cold starts pay every time.
• A fork that consults past dead ends skips re-walking them.
• A retry loop that checks known failure modes skips the doomed attempts.

Run the comparison over time. A stack without retrieval has flat cost per task, forever - task number five hundred pays exactly what task one paid, because nothing carries over. A stack with capture and retrieval has declining cost per task in every area it revisits: each session both draws on the reservoir and adds to it, so the discount grows. That's the compounding curve - and this is the first part of the series where it's a mechanism rather than a metaphor. The gap between the two lines is the accumulated replacement cost you didn't pay.

The same curve explains why this matters more, not less, as agents take over more of the work. Agents multiply session count. Without retrieval, that multiplies the number of cold starts paying full price. With it, it multiplies the rate at which the reservoir fills and the discount deepens. Agents don't change the economics; they turn the volume up on whichever economics you've chosen.

The plateau

Now the honest caveat, because this curve doesn't rise forever on capture and retrieval alone.

Retrieval quality is a function of what's in the reservoir - and a reservoir that only ever fills, degrades. The March learning gets contradicted in July, and search happily serves both with equal confidence. The over-capture that Part 2 correctly recommended piles up noise around the signal. Context packs bloat. The corpus becomes exactly the landfill-with-a-search-box that gave knowledge bases a bad name, except you built it on purpose.

Capture stops the leak. Retrieval makes the reservoir drinkable today. Keeping it drinkable - reviewing, reconciling, refining the raw material on a schedule, so the asset appreciates instead of rotting - is the final part.

Next in this series: Distillation - making knowledge appreciate.