For two years the reflex has been the same. If an agent cannot find the right answer, build it a better index. Chunk the documents, embed them, add a reranker, then a knowledge graph, then summaries over the graph. Each layer adds more machinery between the question and the answer, and each layer promises that this time retrieval will finally be solved.

The labs that actually build the models went the other way.

Claude Code started with a vector database over your repository and then quietly dropped it. Letting the agent read the files directly turned out to be simpler, fresher, and far less of a security problem. Claude’s own memory is not a vector store either. It is a folder of Markdown files that the model reads at the start of a session, which Anthropic describes, without irony, as a personal wiki. Karpathy spent a week of 2026 persuading everyone to do the same thing by hand.

The pattern underneath all three cases is the same, and it is worth naming.

Warehouse versus notebook

A retrieval index is a warehouse. Every question sends a worker running into the stacks to grab a few boxes, skim some scraps, assemble an answer, and then forget the entire trip. The next question starts the run from scratch. The warehouse never gets smarter. It only gets bigger, and a bigger warehouse means a longer run.

A notebook is the other model. The agent keeps its knowledge as plain text that it can read the way you would read a wiki: flip to the page, follow the link. When something is not in the notebook, the agent looks it up once and writes it down. And every so often it tidies up, merging duplicate pages, reconciling entries that contradict each other, and filling the gaps it kept tripping over.

You search a warehouse. You keep a notebook. Only one of them is smarter next week than it was this week.

Write less, on purpose

The trap is reading “write it down” as “log everything,” which rebuilds the warehouse inside the notebook. The discipline lives in the write step, which should be small, opinionated, and run after the fact:

// after answering something worth keeping
const page = await consolidate(answer, sources, {
  merge: existingPages,      // fold into what's already there
  flag: "contradictions",    // surface conflicts, don't silently overwrite
});
notebook.upsert(page);       // plain markdown, in git

Consolidation is the part people skip, and it is the part that matters. Staleness is not an AI problem. It is a cache-invalidation problem. A page is derived from some sources, so when those sources change the page is stale. Mark it, and rewrite it the next time someone opens it. Track that lineage, and freshness and provenance both fall out of the same bookkeeping, because every claim points back to where it came from.

The honest version

This approach is not magic and it is not universal. A notebook still struggles with questions whose answer lives only in a relationship spread across a hundred documents. “What do all our contracts have in common” is a graph problem, and pretending otherwise just produces a confident, wrong page. The background tidying is real work, and a lazy model that never reconciles will quietly let the whole thing rot.

But the trade is a good one. Plain text in git means a human can open the file and fix what the model got wrong, which you cannot do with a vector embedding. The knowledge stops being a black box that answers questions and starts being an asset that accumulates. You stop betting your architecture on the index becoming clever, and start betting on the boring approach that already won: write it down, keep it readable, and tidy it on a schedule.

The model was never the bottleneck. The notebook is.