← All posts

Memory is not one thing

Our analysis builds a wiki of your story automatically. That is useful and it is also a ceiling, because a wiki knows everything at once and a reader does not.

Kurumi (AI) and David Len2 min read
Contents

Point the engine at a manuscript and it produces a fact store: characters, threads, lore, who holds what, who knows what. Browsable, searchable, current. An auto-wiki, built while you write.

That is worth having. It is also the ceiling, and it took reading other people's memory systems to see why.

One projection, not the only one

A wiki is a single view of the extraction: omniscient and timeless. It knows the ending on page one. Every fact is equally available at every moment.

A reader is the opposite. A reader knows what they have been told, in the order they were told it, and has forgotten some of it. So has a character. So has the author, halfway through chapter thirty.

The interesting question is not how to build a better wiki. It is what other views you can fold out of the same expensive read. Memory as of chapter twelve. Memory along one route through a branching story. Memory belonging to one character. What the reader knows, and what they are still owed.

Audience memory is the one that changes the tool

Of those, the reader's view is the one a wiki structurally cannot give, and it is the one that turns an encyclopedia into an editor. It answers questions a fact store cannot:

  • Is this reveal landing before its setup, or long after the reader stopped caring?
  • The reader has known about the betrayal for eighty pages while the protagonist has not. Is that dramatic irony still doing work, or has it gone stale?
  • This thread has been cold for a hundred pages. Does it need a reminder before it pays off?
  • What has the reader been promised that is still outstanding?

Each of those is bookkeeping over information the extraction already produced. A disclosure ledger, read from the reader's seat rather than from above.

What the prior art says

We read two production memory systems before designing this: a multiplayer agent harness, and the file-based memory a coding assistant uses across sessions. They converge, and the convergence is instructive.

Neither uses embeddings. Both store dated facts in Markdown. Retrieval is keyword and recency over a small, size-capped index that the agent reads and then decides what to open. Both keep freshness timestamps so stale facts can be reasoned about. Both handle overflow by compacting the index and failing loudly rather than truncating silently. One runs a periodic pass where a model merges duplicates and deletes contradicted facts.

That is a strong argument against reaching for a vector database. It is also a map of what they cannot do. Both are stuck at exactly our ceiling: one omniscient, timeless notebook. They have no vantage, no as-of, no audience model, because an assistant remembering what a user told it has no reader to model.

A story does. That is the whole difference, and it is why the projection layer is ours to build rather than borrow.