Your Agent's Wiki Is Not Its Memory

Files Won, and That Part Is Right

On 30 June, Harrison Chase published Wiki Memory: agent memory as "an agent-maintained data structure that represents source knowledge in an agent-friendly way," built as a set of files, because unlike retrieval-augmented generation, which re-chunks raw data on every query, a wiki "precomputes and maintains a higher-level synthesis, so the agent does not have to rediscover the structure every time."

He is right. Files won. A maintained synthesis beats re-deriving the world on every query. It is also not new: it is Karpathy's LLM-wiki sketch, and the same week Microsoft Research shipped Memora, which takes the opposite position on legibility. The commentary framed it as a binary, machine-optimised versus human-legible: pick which failure you would rather debug later.

None of it was news to me. I had been running file-based agent memory in production since April, months before this post went up, for exactly the reasons he gives. So when Chase published, I did not learn the approach. I recognised it.

What I had also learned, the expensive way and well before anyone wrote it up as best practice, is the part his post has not reached yet. Files are right. A wiki over them is genuinely useful, and I later built one, as a view on top of the store. But the wiki cannot be the memory. Make that mistake and you do not get a slightly worse system. You get a confidently wrong one.

I know, because I made it first. Not from a blog post. From an ABS deal, and an agent that had a memory and still could not finish.

What Broke on the Mercedes Deal

Earlier this year I built a cashflow engine for structured finance and put an agent in front of it. The test case was a live European auto ABS: Mercedes-Benz, Silver Arrow S.A. Compartment 20, EUR 744.7m, issued October 2025. The agent reads the offering circular, a couple of hundred pages, extracts the deal parameters, builds a model, and projects the cashflows through the waterfall period by period. Weeks of work, across many sessions.

Start with the part that did not break, because it is the part everyone assumes is the problem. The agent had a memory. A decent one. It persisted across sessions, and it was backed by a stack of wiki-style pages: how this deal type behaves, how that one settles, where to look for what. Amnesia was never the issue. It remembered plenty.

It failed anyway, and the reason is subtler than forgetting, and more dangerous.

The pages were flat. And a flat page, to an agent reading it, looks finished. It presents itself as the whole picture. So the agent would pull up the page for a part of the deal, find most of what it needed sitting right there, and conclude it was done. It got lazy at exactly the wrong moment, one level short of the answer, because nothing on the page suggested there was a level below it. I spent a long time trying to break that habit and never fully managed to.

The worst version of it still bothers me. The agent would look at a page, expect a particular term or number to be there, not find it, and conclude the term was not in the deal at all. Absence from the page read as absence from the deal.

In structured finance that is not a small mistake. A trigger it did not find, a step in the waterfall it did not see, a rate that lived three clicks deeper than the page it stopped at: each one is a model that comes out quietly, confidently wrong, and nothing on the page tells you to keep looking. The page does not know what it is missing, so neither does the agent reading it.

Underneath that, the store was filling with the opposite problem. The agent would find the same fact more than once, on different passes, and file it under a different name each time. Read the swap section twice, understand it slightly differently each time, and this is what the memory held, verbatim:

swaps.0.notional = 1,750,000,000   (verified, p8)
swaps.1.notional =   500,000,000   (verified, p45)
swaps.2.notional =   750,000,000   (verified, p45)

Three swaps, three billion euros of notional, every one tagged "verified" with a page number. The deal has one. The memory did not get emptier as it failed. It got fuller, and less true.

Here is the thing a flat page cannot do: tell you what it is not telling you. It cannot say "there is more here, this connects to that, this is one of five things you need and you have found two." It has no edges. It is a dead end that looks like a destination.

I did get the report out, in the end. It took a frontier model driving the Claude Code harness, and even then not in one pass: repeated runs, and a great deal of me sitting over it, forcing the digging the flat pages let it skip. What I had at the finish was one deal muscled across the line, not a process I could point at the next one.

That was the lesson, and it is the reason the thing that replaced it is called Engram. An engram is the trace a memory leaves in the brain, and the brain does not store it as a page. It stores it as a network: a thing wired to the things that explain it, cause it, precede it, and contradict it. A graph will not let an agent believe it is finished, because every node shows its neighbours. The page says you are done. The graph says keep going.

The Same Mistake, One Level Up

Once you have felt that failure, you notice something about every flagship example of "wiki memory." DeepWiki from Cognition, OpenWiki from LangChain, AutoWiki from Factory: every one is a wiki over a codebase. And that detail does silent, load-bearing work.

A code wiki can afford to be wrong, because the source survives. And these are wrong: LibreOffice maintainers found DeepWiki claiming their project builds with Buck, which it does not, and one careful reviewer found every section "seemed fine on first brush" but "contained at least one minor factual issue on closer inspection". None of it is fatal, and the reason is the whole argument: the code is still there. A maintainer reads a wrong page, knows it is wrong, regenerates it. The truth was never in the wiki. It was in the code the whole time.

Now point that architecture at memory. The agent compresses we decided X in April, then reversed it in May because the evidence was a misread footnote into a page that reads X. There is no repository behind that page. The reasoning is gone, the reversal is gone, and nothing rebuilds them, because nothing else ever held them. A code wiki's compression is lossy and reversible. A memory wiki's compression is lossy and one-way.

Which is why staleness in a memory wiki is not untidiness. It is a correctness bug, and a confident one, because nothing on the page tells you it went stale before a human prices a deal off it.

What Actually Worked

First, the honest part of the chronology, because it matters. That deal did eventually ship. I ripped out the existing open-source computation library I had been trying to bend into shape, wrote my own deterministic engine, and got the report out.

Ripping out the engine fixed the arithmetic. It did nothing for the memory, because the memory was never a computation problem. The engine had been computing faithfully the whole time. It was being handed a flat, over-trusting picture of the deal. So a few weeks later, in April, I rebuilt the memory around the two things a flat page cannot do.

I did not start from a blank page. The bones came from MemPalace, an open-source memory system I had been running, whose wing-and-room hierarchy I kept and adapted, probably further than its authors intended. The idea that turned it into something else, the graph, grew out of a run of conversations with Zac Ruiz, who is building CMD+RVL. A hierarchy tells you where a memory lives. A graph tells you what it connects to. It was the second half that mattered.

Edges. The memory knows what it is missing. Every record is a node in a graph, wired by typed links to the things that explain it, cause it, precede it, and contradict it. That sounds academic until you watch what it does to the agent's behaviour. It can no longer treat a page as the whole world, because the node it is reading openly points at its neighbours. "You have found two of the five things connected here" is a fact the graph carries and a flat page structurally cannot. The agent stops concluding it is finished the moment a page looks full, and stops reading a blank as proof of absence, because the structure itself says there is further to go. This is the part I never cracked with prompting, and it turned out not to be a prompting problem. It was a shape problem. The brain does not store a memory as a page either. It stores it as a trace in a network, which is what the word engram means, and a network is the one structure that can tell you there is more.

Supersession, made explicit and first-class. The second thing a flat page cannot do is say this replaces that. So now every record is its own dated file, and nothing is ever overwritten. When an understanding is replaced, the old one is not deleted. It is marked superseded, and the new one carries a typed link back to what it replaced. The agent cannot silently pile up the same fact under three names, because writing the replacement requires naming what is being replaced. The pile becomes a chain, and a chain has a head.

So "which of these readings of the swap is live" stops being a guess and becomes a lookup: follow the chain to its head. The record that settles it looks like this:

id: eng-0412
topic: One interest-rate swap, EUR 744.7m notional (not three)
supersedes: eng-0288
caused_by: eng-0407
provenance: offering circular, p.45

supersedes names the dead three-swap reading, so the agent cannot find both and pick one. caused_by records what changed my mind. provenance lets the claim be checked against the document rather than believed. And eng-0288 is still there, still readable, still wrong, marked as history, because the wrong belief is the most useful thing in the store: six weeks later somebody reads that swap section too fast, reaches the same wrong count for the same reason, and the record already says why it is wrong.

And the wiki sits on top, as a generated view. No human edits it. Only the live head of each chain renders as current fact; every superseded understanding stays reachable behind a labelled revision link, as it read at the time. Staleness presented as current is a bug. Staleness presented as history is the most valuable thing in the store. That is only possible because the layer underneath never threw the old version away.

Two views, one store. The agent retrieves from the store. The human reads the wiki. Neither is the other's master. It has been running since 10 April: 1,333 live memories, 156 archived, across nine projects, including the deal work that produced it.

The Binary Is False

So I do not accept the choice the field set up this month. Legible or opaque. Auditable or efficient. Pick your failure.

You do not pick. You layer.

The record is legible, atomic, and authoritative. The index is opaque, fast, and rebuildable from the record. The wiki is readable, synthesised, and also rebuildable from the record. Delete the index and the wiki tomorrow morning and you have lost precisely nothing, because the record was the only thing that was ever true.

The obvious objection is that I have described event sourcing with extra steps, and that this is thirty-year-old data engineering wearing a new hat.

Yes. Exactly that. Keep the log, derive the views, and never let a derived thing become the source. It is one of the most thoroughly settled ideas in the discipline, and agent memory is currently re-learning it from first principles, at speed, in public. We spent two years learning not to mistake the index for the data. We are three weeks into making the same mistake with wikis.

The Part That Actually Broke

One more finding, and it is the one that surprised me most: none of the above is what failed hardest.

The retrieval worked. The graph worked. The files worked. What failed, over and over, was that the agent would not use any of it unless something forced it to. It would answer from thin air rather than search, and end a turn without storing the decision it had just made. And retrieval quality is a completely irrelevant metric on a query that nobody ever runs.

A perfect memory system used twenty percent of the time is worse than a mediocre one used every time.

You cannot fix it by asking, either. The instruction sits at the top of the config file, in capitals, and it works for about twenty minutes, until the context fills and the model's own prior, to answer directly and not make extra tool calls, quietly wins. What fixed it was removing the choice, and that is the next piece.

This is the first of three. Part 2: the memory problem is a discipline problem, and instructions cannot solve it. Part 3: I watched a release collapse by thirty-three points on its headline metric, came close to reverting all of it, and found the system was fine and the number was lying, for a reason that almost certainly applies to whatever you are currently measuring.