The Bet You Can’t Avoid

Every system you use to remember your own work is a bet about your own future ignorance. You cannot keep everything and still engage with any of it, and you cannot curate down to what matters without deciding, now, what will matter later. So you choose. Either you pay at capture time, distilling each session into something small and addressable and letting the rest go, or you pay at query time, keeping everything and trusting search to find the part you need. Both are bets. Both lose something quietly. The only real question is which of your future selves you would rather burden.

I made that bet years ago, and until recently I had stopped noticing it was a bet at all.

A quick word on how this goes, so the turns do not catch you off guard. I start with the tool that set me off, then build the strongest case I can that the whole category is unnecessary, that working developers already solved memory and never felt the gap. Then I spend the rest of the essay complicating that case, because the tidy version quietly hides what it throws away. Only once the real choice is on the table do I show my own hand: which side I bet on, where I inherited the bet, and what it costs me. I keep my verdict, including the part where I concede the other side is right, for the end, because the verdict was never the point.

The Tool That Reopened the Question

What made me notice again was a tool. In April 2026 a repository called MemPalace¹ gathered tens of thousands of GitHub stars within a fortnight and topped the category’s benchmark. Three months on, the aftermath is more instructive than the launch. Demand is real: it is still installed something like 70,000 times a month. But its distinctive idea has not held up. Independent teardowns traced the headline retrieval score to the underlying vector store rather than to MemPalace’s “memory palace” layer, which if anything lowers accuracy[2]. Its own production users, meanwhile, report that the memory file grows until it “became the problem it was designed to solve."[3] That last sentence is this whole essay in miniature, and I will come back to it.

MemPalace is not really the subject here; it is the occasion, the current form of a standing question about agentic recall. My answer to that question has been the same for a decade: pay at capture.

• I run extract-on-write.
• At the end of a session I distill what mattered into notes, commits, and memory files, and I let the raw transcript go.
• I pay that cost up front, at capture, on purpose, because I decided long ago that handing my future self a small curated set of letters is more respectful than handing him a searchable landfill.

That said, the crowd betting the other way is not confused, and watching it grow is what knocked me off autopilot and turned my long-settled answer back into a live question.

What MemPalace Actually Does

The design is a deliberate inversion of Retrieval Augmented Generation (RAG) inherited assumptions. In a RAG pipeline built for conversations the usual flow is: take the chat history, use a large language model (LLM) to extract “facts” or “events” from it, store those facts in a vector database, and retrieve the facts at query time. Every step is lossy. Extraction rephrases. Summaries lose the exact wording that your later query would have matched against. Facts flatten context. The architecture assumes that conversations need to be transformed into a retrievable form before they can be searched.

MemPalace rejects that premise. Conversations are already the right unit of retrieval. Store them verbatim. Embed whole sessions. Retrieve whole sessions. Skip extraction entirely.

Around that core the system adds a structural layer borrowed from the classical method of loci: content is filed into wings (projects or people), rooms (topics within a wing), and drawers (individual items in a room). The wings and rooms work as metadata filters that narrow the search space before vector similarity ranks the candidates. This is standard information-retrieval logic: shrinking the corpus before ranking improves recall. The classical naming is mostly cognitive scaffolding for the user designing the schema, not a new retrieval algorithm.

The architecture is coherent, but coherent is not the same as load-bearing. When independent reviewers pulled the benchmark apart, the headline 96.6% turned out to belong to the underlying vector store. The retrieval path that scores it uses essentially no MemPalace-specific logic, and the palace layer that gives the tool its name, the wings and rooms and drawers, measurably lowers accuracy when you switch it on. That is the same observation as the paragraph above, sharpened by data. The classical scaffolding helps the human designing the schema; it does not help retrieval. What survives the audit is narrower than the launch implied but still real: verbatim retrieval over whole sessions, with zero model calls in the path, holds its own against pipelines that spend a model call per stored fact. The tool is local-first, free, and written in Python. If you have a corpus of LLM conversations you wish you could search, it is a reasonable option. But the interesting thing was never the tool. It is the premise underneath it.

The Problem Developers Already Solved

The sharpest test of the capture-at-write bet is the developer, because a developer already lives inside memory systems built on exactly that principle and rarely feels a gap. There are two of them. The first has been solving “durable collaborative memory” for thirty-plus years: version control, specifically git. If you list the features the AI memory category is trying to provide, git already ships every one of them:

• Immutable event log. Commits, ordered, cryptographically hashed.
• Attribution. Author, committer, signer, co-authors.
• Causality. Parent pointers, merge topology, cherry-pick provenance.
• Addressability. Secure hash algorithm identifiers (SHAs), tags, refs.
• Projections. Branches, worktrees, views, cherry-picks.
• Time travel. Check out any point in history and reconstruct the working tree.
• Review. Pull requests, diffs, inline comments, approvals.
• Discussion. Issues, threads, cross-references.
• Discovery. git log, git blame, git bisect, git grep.
• Governance. Signed commits, branch protection, required reviews.
• Collaboration semantics. Merge, rebase, conflict resolution.

A ten-person team working on a ten-year-old codebase does not have a “memory problem”. Every decision that mattered is recorded, attributed, reviewed, and queryable. They work on one piece at a time, in isolation, because the repository remembers itself. They do not hold the whole system in their heads; they hold git log, git blame, and the professional discipline to leave good commit messages. That is enough for the class of questions commits are designed to answer.

The key insight is that git’s memory was never designed as a memory system. It emerged as a side effect of a disciplined workflow. The act of committing code is also the act of placing a drawer in a room in a wing of the palace. Nobody has to file anything manually because the act of working files itself. Git is what you get when the memory structure is built from the work rather than curated alongside it.

The second system is newer and easier to overlook because it does not feel like storage. When a developer works with an AI coding agent, the model brings its own memory. The context window holds the live session, and the harness around it carries what should persist between sessions: Claude Code’s CLAUDE.md, its memory files, the machinery vendors build to keep a long session from drifting into incoherence. This is memory too, and it splits along the same seam as everything else here. The context window is pure retention, and it evaporates the moment the session ends. The harness files are curation: a CLAUDE.md is a hand-written distillation of what the agent should always know, extract-on-write wearing a config file’s clothes. The durable half of the developer’s AI memory is curated by hand, the same shape as git.

So both systems a developer already relies on sit on the curation side of the bet. Git curates decisions through commit discipline; the harness curates working context through hand-written memory files. Neither retains the raw stream, and neither has to, because between them they answer the questions the work actually raises. That is why the gap is invisible from inside the workflow: the developer is already paying at capture, in two places, and it works well enough that a retain-everything tool looks like a solution to a problem they do not have.

So far this is the naive version of the argument: developers have git and a curated harness, so developers do not need AI memory. That version is wrong, and it took me a while to see why.

What Commits Deliberately Discard

To price the curation bet, look at what the curated artifact throws away. In git that artifact is the commit, so start there. Consider a two-hour session with Claude that ends with a 40-line commit titled “migrate auth to session tokens.” The commit is the output. What was in the two hours?

• Four approaches considered.
• A middleware rewrite rejected because of an obscure initialization-order bug.
• Thirty minutes of wrong diagnosis (“I thought it was a database issue”).
• A specific prompt that finally got the model to explain the OAuth quirk.
• A decision tree whose branches are mostly pruned in the final code.
• The exact sequence of errors that led to the right solution.

The commit keeps the verdict. The pull request (PR) description keeps a sentence or two of rationale. The test plan keeps a checklist. None of them keeps the reasoning texture: the shape of the thinking that produced the output. That shape is in the transcript.²

Five categories of signal live in transcripts and are systematically absent from git:

1. Reasoning texture. The rejected branches, the initial diagnosis, the “we considered and dismissed” paths. Commits record the chosen branch and discard the others.

2. Sessions that produce no artifact. Exploratory debugging, learning a codebase, reading a paper with the model, designing a system that has not been built yet, doing research, writing prose. None of this commits. For heavy Claude Code users, a substantial fraction of their most valuable work leaves no git trace at all.

3. Negative knowledge. “I tried this three months ago and it didn’t work.” Git cannot show a dead end that never became a commit. The transcript can.

4. Prompt discovery. “How did I get the model to do this successfully last time.” The exact prompt matters (sometimes it is the whole difference between a useful answer and a useless one), and git does not store prompts.

5. Cross-repository continuity. Git memory is per-repository. A senior engineer working across twenty repositories has twenty disjoint memory silos. The conversation layer is the only substrate that crosses them.

Smart developers are not ignoring their existing memory when they adopt MemPalace. They have git and a curated harness, they know what each is for, and they have noticed that five specific kinds of signal slip through both. The memory palace is what catches them.

Two Strategies for the Same Observation

Git just showed you one strategy running inside a tool: curate at write time, discard the rest, and accept the five losses as the price. Step back from git and there are exactly two ways to answer the observation that transcripts hold signal commits discard. They are both defensible, and they produce different tooling because they answer different questions.

Extract-on-write. At the end of each session, decide what is worth keeping, write it down in a durable form, discard the rest. In practice this looks like a reflection step (I use a /retro command) that distills the session into memory files, vault notes, commit messages, issue comments, or post-mortem documents. The transcript is then disposable because everything worth keeping has been graduated to an addressable artifact. Storage cost is low; the index stays curated and small; future queries hit hand-written summaries rather than raw dialogue.

Index-and-query. Retain the whole transcript, index it semantically, and pull what you need when you need it. The extraction is deferred from write-time to read-time and delegated to vector similarity. Storage cost is higher; the index is noisier; but nothing is thrown away, and queries you did not know you would ask in advance are still answerable.

Both strategies solve for the observation that transcripts contain signal commits do not preserve. They disagree about where to pay the cost of extraction. Extract-on-write pays it once, at session end, with curation discipline. Index-and-query pays it per query, with search infrastructure.

The two strategies are not equivalent. Each has failure modes the other does not:

• Extract-on-write fails on unknown-unknowns. If you do not know at session-end that some fragment of reasoning will matter six months later, you will not extract it, and it will be lost. The strategy assumes you can predict which signal is worth preserving. That assumption is load-bearing and sometimes wrong.

• Index-and-query fails on signal-to-noise. Keeping everything means every query competes with the bulk of low-value content. Retrieval tuning matters more. As the corpus grows, the probability that a query surfaces irrelevant-but-similar material grows with it. The strategy assumes vector search will stay useful at scale; given the operational walls of current vector stores, that assumption is also load-bearing.

There is no architecture-level argument for preferring one over the other. There is a workflow-level argument: if your sessions tend to produce crisp artifacts you can comfortably summarize at end, extract-on-write is cheaper. If your sessions are long, exploratory, and often fail to produce artifacts, index-and-query recovers value the other strategy would discard. Most real users are somewhere in between, and many of them would be better served by running both simultaneously than by picking one.

My Bet, and What I Might Be Missing

I have been running extract-on-write for months. It works well for my stack because my stack is structured around it: persona-based agents, a git-tracked knowledge vault, a coordination substrate with addressable posts, enforced commit discipline, a hand-curated always-loaded memory index. Every meaningful output lands in some system that has its own memory model. The chat stream is secondary. The projections are primary.

When I say “I do not need MemPalace,” what I accurately mean is: I have bet that the signal worth preserving can be identified at session end. The bet is not that transcripts contain no value (they clearly do), but that the marginal value of the signal I miss at extraction time is lower than the cost of indexing everything.

That bet has visible failure modes, and I should be honest about them. The specific classes of query I currently cannot answer well, and which MemPalace would answer:

• How has my thinking about X evolved across sessions? My memory files capture final positions, not the trajectory. A query over transcripts would show the drift.
• What prompt worked last time for this pattern? I remember results, not the exact invocation that produced them.
• Have I already solved this problem? If I am about to re-do work I did six months ago in a different context, I will not notice unless the prior work produced an artifact I can grep.
• What did I try and abandon? Dead ends leave no commits. My /retro might capture one, but I trust my session-end judgment more than I should.
• What patterns repeat in my own mistakes? Cross-session analysis of my own reasoning is something I cannot do from projections alone.

Each of these is a legitimate question, and for each one my extract-on-write bet actively prevents an answer. The people adopting MemPalace have chosen a different bet: they retain the raw material so that questions like these remain answerable, even at the cost of a noisier index and a larger store.

The Memory Problem I Already Had

My bet is not neutral; it grew out of my own memory problem, and a specific lineage of trying to solve it. Naming that lineage seems fair, because readers inside it will recognize themselves, and readers outside it will understand why the argument may not map to their situation.

The first move was Getting Things Done[4]. What I took from it was that uncommitted memory imposes a cognitive tax: open loops carried in your head leak attention even when you are not consciously thinking about them. The answer was not to remember harder but to externalize, and the externalization was purposive, not archival. The point was never to keep everything, it was to stop paying for holding everything. Then I extended it backward. Tasks recur, but an insight you do not capture in the moment is usually gone, so externalizing ideas has a harsher failure mode than externalizing tasks: the input does not come back.

Then I tried to solve capture with OneNote. A few gigabytes in, I had a corpus I could not engage with. Search returned too much. Organization fought the tool. The capture was happening; the retrieval was not. This is the experiment that matters for the rest of this essay, because it is structurally the same experiment MemPalace proposes. Retain everything, trust the index, defer processing to query time. I ran that experiment for a couple of years and found that the index-everything-search-later bet does not deliver the engagement it promises. A corpus you cannot engage with is dead weight regardless of how searchable it is. That is not theory for me. It is scar tissue.

The third move was Zettelkasten, encountered via an episode of Jorge Arango’s The Informed Life podcast[5]. The reframe that mattered was not “keep better notes” but “notes are correspondence between temporal selves.” From that episode, Austin Govella:

“If the only audience for your note-taking system is just you, even then, it’s not just Present You. It’s Past You and Future You as well.”³

Past-Self leaves breadcrumbs. Present-Self processes them, connects them with new context, and writes the next letter. Future-Self receives the network and extends it. Note-taking under this framing is not storage. It is deliberate correspondence across time, and it only works if the letters are actually written. A retention system does not write letters; it only keeps raw material. That distinction looked decorative to me at first and turned out to be load-bearing.

Obsidian became the tool because markdown, flat files, and wikilinks fit the correspondence model. Initially I used it the way I had used OneNote, which is to say as a filing cabinet. Over time, the tool’s features and the Zettelkasten discipline pulled me toward atomic notes, explicit links, and Maps of Content. The vault started to feel like a working network rather than an archive. It also started to hit a ceiling that manual linking could not solve: past a certain number of notes, you cannot remember what is related to what, and the act of looking for relevant material becomes its own form of cognitive tax, the thing GTD had originally taught me to avoid.

When Personal Knowledge Management Meets the LLM

Everything up to here was PKM: me working out how to keep my own notes usable for myself. Then that practice met the model, and its purpose quietly widened.

That ceiling, the one manual linking could not solve, is what DEVONthink[6] had gestured at years before LLMs: its premise is that intelligence over a curated corpus is what you want, not intelligence that produces one. I never switched to it, but the idea of associative surfacing over hand-curated notes stayed with me as the feature Obsidian was missing. Meanwhile I had started treating the vault as code rather than prose,⁴ which, without my planning it, left the corpus structured enough for a machine to operate on. So when LLMs arrived they did not fill a void; they filled exactly that missing feature, slotting into a position I had spent years preparing. I came to AI expecting the DEVONthink promise delivered at last, not a new kind of memory system.

But that framing kept the assistant in a supporting role, as intelligence pointed at my corpus. What reorganized everything was noticing that the assistant has a memory problem of its own, and a worse one than mine. My notes exist; I just cannot always re-engage them. The assistant has no notes at all: it starts every session blank, remembers nothing from yesterday, and forgets the current conversation the moment it closes. I had spent a decade learning to write for my own future self. The assistant is a future self with no past self, unless something writes one for it. That is where my note-taking stopped being personal. The discipline I built to correspond with myself turned out to be the one thing that could give a stateless assistant a past, and the bet I had been making about my own memory quietly became a bet about its.

There is a single ethical principle running through this whole lineage, and it is worth making explicit: the cost of knowledge work should be front-loaded onto Past-Self. Capture time is where you pay. Future-Self receives curated, atomic, addressable artifacts. The retention tradition inverts this distribution: Past-Self pays nothing, Future-Self pays the cost of wading through noise to find signal. Both approaches distribute the cost across your temporal selves. They simply disagree about which self it is fairer to burden.

The curation tradition decided, implicitly or explicitly, that front-loading is more respectful to the future. I came up through a lineage that decided this decades before I did, and I inherited the decision without examining it for years. Writing this essay is partly the act of examining it now.

None of this means the retention tradition is wrong. It means my resistance to it is not aesthetic and not arbitrary: it is the result of having already lived through the OneNote experiment and having adopted, over a decade, a set of practices built around a specific ethical stance toward my future selves. A reader from the retention tradition is correctly solving a different problem with a different stance, and the tools they adopt are consistent with that stance.

Knowing where my bet comes from is also what lets me read my own blind spots honestly. Front-loading cost onto Past-Self only works if Past-Self has good editorial judgment about what Future-Self will want. When that judgment is wrong, the loss is silent and permanent. That is the trade I have made.

The Convergence

The pattern I arrived at through this specific sequence has, in the last year, started to become a mainstream position. Two communities that do not usually listen to each other are converging on it from opposite directions. The PKM crowd is discovering that language models make a curated corpus come alive. The AI-builder crowd is discovering that LLMs without a curated corpus reset every session, and that building substrate from scratch is harder than adopting an existing one. Both groups are arriving at “LLM plus markdown vault” as the working unit. The tool most of them end up using is Obsidian, for the same reasons I did: flat files, wikilinks, plugin ecosystem, and markdown as a substrate that is both human-readable and machine-tractable.

The convergence became culturally legible in April 2026 when Andrej Karpathy published a GitHub gist he calls the LLM Wiki [7].⁵ The pattern is straightforward: dump research materials into a folder, point a language model at them, and let the model incrementally build and maintain an interlinked Markdown wiki, writing articles, creating backlinks, categorizing concepts, and keeping the structure current as new material arrives. Karpathy’s workflow puts the model on one side of the screen and Obsidian on the other, with Obsidian acting as the interface for browsing the wiki the model is writing.

Karpathy’s framing grounds the pattern in Vannevar Bush’s 1945 essay “As We May Think,” which described a hypothetical device called the Memex: a personal, curated knowledge store where a user could create associative trails between documents. The Memex never shipped because the maintenance cost was manual and therefore crushing. Karpathy’s claim is that LLMs close the gap: “the tedious part of maintaining a knowledge base is the bookkeeping,” and language models do bookkeeping at near-zero marginal cost. The Memex now works because the curator can be delegated.

It is worth noting exactly what Karpathy’s variant does and does not claim. It does not claim that curation is dead. Quite the opposite: the LLM Wiki is a curated artifact, structured into articles, backlinks, and categories. What changes is who does the curation work. Karpathy lets the model maintain the structure; I still curate by hand, with model assistance, through my session-end reflection step. Both approaches sit firmly in the curation tradition against pure retention. The debate inside the curation tradition is now about how much of the processing the human has to do, not about whether processing matters.

That is the interesting frontier. Retention-tradition tools like MemPalace argue that processing can be skipped entirely if retrieval is good enough. The emerging curation-tradition consensus, which includes Karpathy’s variant and mine as two different points on the same axis, argues that processing is non-negotiable, and the open question is only who or what performs it. For now I still perform most of mine myself, because I have not yet decided whether I trust a model to maintain a corpus whose purpose is correspondence between versions of me. That is not a technical reservation. It is a question about whether a model’s judgment about what matters to Future-Self is close enough to my own. I do not know the answer, and I think it is the right question to ask next.

The Category and Its Ceiling

MemPalace and its competitors sell a real service to users who have noticed that transcripts contain signal commits discard. Framed this way, the category has a legitimate ceiling: it is capped by the amount of signal that cannot be extracted at session-end and will be lost without retention. That is a real quantity, probably larger than extract-on-write users would like to admit, but smaller than the category’s current marketing implies.

The category also has an unhelpful tendency to conflate its value with the broader claim that LLM interactions need a new kind of memory system. They do not, for most of the information they generate. Code decisions still belong in commits. Architecture still belongs in documents. Coordination still belongs in issues. The part that does not fit anywhere is the reasoning texture, the exploration, the failed branches, the prompts that worked. That is a real gap, and filling it is valuable. But it is a narrower claim than “AI memory is a new category,” and the tools would be sharper if they positioned themselves that way.

The naming is load-bearing. “Memory” invites an open-ended scope that is hard to contest and hard to evaluate. “Transcript retention with semantic search, for questions commits cannot answer” is a specific, evaluable claim. The latter is closer to what the category actually provides and what its users actually need.

What the Framing Reveals

There are two honest conclusions, and they do not cancel each other out.

First: for anyone building agent infrastructure beyond a single user experimenting in a chat window, the right place to start is one question: what durable artifact does your agent produce from this interaction? If the answer is “the transcript,” the workflow is not yet designed. If the answer is “a commit,” “a pull request,” “a note in a tracked vault,” “a post with an addressable identifier,” the workflow is designed, and the memory problem is largely solved.

Second: projections are not a complete replacement for retention. Commits are a lossy projection of the thinking that produced them. Some questions can only be answered from the raw transcript, and no amount of discipline at the projection layer will recover them. Users who retain transcripts and index them are solving for that gap. They are not confused about git; they are supplementing it.

The method of loci worked for Greek orators because the palace was built from their speeches. They placed items along a path that mirrored the structure of what they wanted to remember. Git works for the same reason: the palace is built from the code, and the structure of the repository mirrors the structure of the work.

MemPalace works on a different premise: that some of what matters never made it into the code, and the palace for that material has to be built from something else. That is true, and I had to watch thousands of developers decide it was true before I was willing to write it down.

For my own stack I will keep running extract-on-write, because the tradeoffs of my workflow make it the right bet. But I will stop claiming the other bet is for people who lack discipline. The other bet is for people who have noticed something I have chosen not to capture. Whether that is a mistake on my part is a question I can only answer by eventually trying their strategy alongside my own and seeing what surfaces that I did not know I had forgotten.

References

1. MemPalace, local-first AI memory system (GitHub, April 2026).
2. MemPalace Review: Benchmark Claims vs Reality, independent teardown finding that the headline 96.6% LongMemEval score runs on the underlying vector store’s default embeddings and that the palace layer lowers retrieval accuracy (Vectorize, April 2026).
3. Feedback from production use: the weight of memory itself, production report that the learnings file grew to 37,000 tokens and “the memory system became the problem it was designed to solve” (MemPalace GitHub issue #514, 2026).
4. Getting Things Done, David Allen’s method for externalizing open loops; the canonical text is Getting Things Done: The Art of Stress-Free Productivity (Penguin, first edition 2001, revised 2015).
5. The Informed Life, Jorge Arango’s podcast on information architecture and personal knowledge practices. The Austin Govella episode is where the three-temporal-selves framing appeared.
6. DEVONthink, macOS document manager with statistical “See Also” surfacing over user corpora. Long-cited as the benchmark for associative discovery over hand-curated notes, well before LLM-based approaches.
7. LLM Wiki, Andrej Karpathy’s GitHub gist describing a pattern for LLM-maintained personal knowledge bases (published April 2026). Explicitly grounds the pattern in Vannevar Bush’s As We May Think (The Atlantic, 1945), the essay that introduced the Memex.