Total Recall — Repo Memory, Retrieval and Context Graphs

Vibe Coding Nights #48 — Total Recall, a Saturday-morning build sprint in the Off the Leash season. A coding agent that forgets your repo every session is one you have to supervise, and the fix is not a bigger context window: loading the whole repo every turn is slow, billed, and makes accuracy worse by burying the relevant two hundred lines in two hundred thousand. The deck's organising idea is that memory is four different things separated by how the agent fetches them — always-on (nothing fetches it, it is just there), retrieval (similarity to the question), graph (following edges), and working (recency) — and every later slide, including all five lab steps, hangs off those four names. Two sections go beyond retrieval. The first is where vector search stops working, presented as three queries a builder can test against their own repo in ten seconds: what breaks if I change this signature (callers do not textually resemble the callee, so similarity returns exactly the wrong set), which of these two config patterns is current (a vector has no notion of time, so a superseded pattern retrieves as confidently as the live one), and who owns the service that writes this table (three hops, no single chunk contains all three). The honest conclusion on that slide is do not start here: build the vector index first, use it for a week, write down the questions it answered badly, and only add edges if they look like those three. The second is a landscape of what actually exists — plain files, Chroma, pgvector, Pinecone, Mem0, Zep/Graphiti, Cognee, Letta — sorted not by quality but by which of the four rows each one covers, with the stated default that files plus a local vector store covers most of what most teams need. A three-slide case study grounds all of it in a real repo in daily use, with every number measured the morning of delivery rather than asserted: a 75,767-byte always-on instruction file re-read before the operator types anything, 313 hand-written memory notes carrying 535 cross-links across 245 unique targets (a context graph nobody set out to design), a 4,493-person derived graph that must never be hand-edited, and a 478-verb capability index built by parsing the source rather than embedding it — the counter-example to the night's own lab, since not all recall is vector recall. The case study is deliberately unflattering: it reports that the always-on file advertises 425 verbs while the generated index has 478, a drift found while building this deck, in the repo the deck presents, and uses it to make the point that memory fails quietly in a way a slow agent does not. The hands-on hour builds the stack on a repo the attendee actually works in: chunk on real function boundaries using Python's built-in ast (chosen over tree-sitter specifically because it needs no build toolchain and cannot strand anyone mid-sprint, with tree-sitter named on-slide as the polyglot upgrade), embed into a persistent local store with path:line ids so re-indexing is idempotent, expose retrieval as a command the agent runs and cite paths and line numbers back, then persist a startup notes file and extract a who-calls-this edge map in nine lines of the same parse — a context graph with one edge type, built by hand, so the landscape slide stops being abstract. 20 slides, per-step checkpoints so nobody is silently stuck until demos, an agent-readable /setup.txt, and a gotchas slide where four of the five entries are about knowing when the memory is wrong rather than making it better.