AI Had a Memory Problem, So I Built a Database For It

Every AI tool I use forgets everything the moment a session ends. The industry’s answer is retrieval: embed the history, search it by similarity, stuff the results into context. It works well enough that most people stopped asking whether it is the right shape.

It isn’t, and the reason is simple. Vector search retrieves what is similar. It cannot tell you what is important.

Ask about payment retry logic and a vector store returns the chunks that look most like your query. Probably some retry code, maybe a config file. What you actually needed was the incident from Q3 where a retry storm double-charged customers, which is why the idempotency keys exist. That memory is not textually similar to your question. It is causally connected to it. Similarity search has no representation for that relationship, so it cannot surface it.

Worse, similarity has no notion of decay. A note from two years ago about a system that no longer exists scores exactly as well as yesterday’s decision, provided the words line up. Everything is equally present forever, which is not memory. It is a filing cabinet with a good index.

What memory does that storage doesn’t

Human memory has properties a database normally treats as bugs.

It decays. Ebbinghaus described the forgetting curve in 1885: retention drops sharply then levels off, and each retrieval flattens the curve. Forgetting is not a failure mode, it is how relevance gets maintained without anyone maintaining it. Things you never return to fade, and that is the system working.

It strengthens with use. Hebb’s rule says neurons that fire together wire together. The association between two memories gets built by the act of recalling them together, not by anyone declaring a relationship. Nobody writes the schema. Usage writes it.

It is uncertain, and knows it. You can be confident about one memory and hazy about another, and you act differently depending on which. A store that returns every result with equal authority is throwing away the most useful signal it has.

Bolting these on top of a vector store as application logic does not work. You end up recomputing decay in a cron job, maintaining an association table by hand, and storing confidence as a column nobody reads. The behavior has to be in the engine or it is cosmetic.

Engine-native primitives

MuninnDB makes those three properties native to the storage engine rather than features of the application above it.

Decay runs continuously. Memories weaken on the Ebbinghaus curve unless they are retrieved, and retrieval strengthens them. A memory you return to weekly stays sharp. A memory from a project that ended fades until it is effectively gone. Still stored, never deleted, just no longer competing for attention.

Associations form from usage. When two memories activate together, the link between them strengthens. Nobody defines the graph. It emerges from how the system is actually used, which means it reflects the real structure of the work rather than the structure someone imagined at schema-design time.

Confidence is Bayesian and carried through retrieval, so results arrive ranked by how much the engine actually trusts them.

The practical consequence is the thing that convinced me it was worth building. You store a note about a payment incident. Weeks later, working on unrelated retry logic, you ask what is relevant right now, and the Q3 incident surfaces. You never mentioned it. Nothing in your query resembled it textually. The engine connected the concepts because that is what the primitives do.

Calling that a better search result misses what happened. The operation itself changed, from retrieval to activation. The question stopped being “what matches this string” and became “given where I am, what should I be aware of.”

What it is not

People reach for the nearest category and none of them fit. It does semantic work without being a vector store. Associations form a graph without it being a graph database. And it is not a RAG wrapper, because the behavior lives in the engine rather than in a pipeline assembled on top of someone else’s database.

It ships as a single Go binary with no dependencies and no configuration, speaks MCP natively so AI tools connect without glue code, and also exposes REST, gRPC, and SDKs. It is open source under BSL 1.1. I also filed a provisional on the cognitive primitives in February 2026, which is a placeholder rather than a granted patent, and I filed it so nobody else could enclose the mechanism and force the project closed.

I am its sole author.

Why this matters beyond my own tooling

The current generation of AI products is bounded by context, not by intelligence. Models are extraordinary and their working memory is a buffer that gets truncated. The industry response has been to make the buffer bigger, which is real progress and also not the same as remembering.

Remembering means knowing what to keep, what to let go, and what to surface unprompted because it bears on what you are doing now. That is a storage problem, and storage has not caught up to the models sitting on top of it.

I built MuninnDB because I needed it. I use it every day across every project I have running. But the underlying observation is not about my workflow. It is that we have been trying to solve a memory problem with a search index, and those are not the same thing.