Wiki memory vs fact memory: LLM wikis and Mem0 compared

7 min read

There are two common ways to give an AI agent memory that lasts beyond one session. A fact store, such as Mem0, pulls short facts out of each conversation and hands the relevant ones back before the next model call. A wiki, Karpathy’s LLM wiki pattern, has the agent write and revise whole pages that link to each other. Fact stores are built for remembering things about each of many users. Wikis are built for knowledge a person or a team keeps working on: how things work, what was decided and why, what the research found.

This post compares the two on what they store, how they are written and read, how they change, and who can see inside them. For the wider set of options (instruction files, RAG, memory blocks), start with our guide to agent memory.

How does fact memory work?

Mem0’s docs describe the flow in two calls. After a useful exchange, your app sends the messages to add. Before the next model request, it calls search and puts the best results in the prompt.

On add, an LLM reads the new messages and the related memories already stored, extracts “preferences, decisions, plans, and other details”, removes duplicates, embeds each fact for semantic search, and records the people, places and projects it mentions. The docs give the shape of what comes out:

You send Mem0 stores
“I prefer aisle seats” User prefers aisle seats
“Let’s use Postgres for this project” Project decision: use Postgres

By default the transcript itself is not kept, only the facts. Memories are scoped by user_id, agent_id and run_id, so one user’s facts never mix with another’s. The automatic path is additive: if a user says they moved from Austin to Seattle, Mem0 “can store the new fact without silently rewriting the old one”, and your app calls update or delete when it needs to correct one.

On search, Mem0 ranks stored facts against the query by meaning, by keywords, by the entities they share with the query and, on its hosted platform, by time. Zep and Supermemory work on the same idea with different storage: Zep keeps facts as a graph with timestamps, and Supermemory keeps a profile per user plus documents. Our Mem0 vs Zep vs Supermemory post compares the three.

How does wiki memory work?

In Karpathy’s gist the agent maintains “a structured, interlinked collection of markdown files” that sits between you and your raw sources. When a source arrives, the agent writes a summary page, then updates the entity and concept pages it touches, often 10 to 15 at once, and links them. An index.md lists every page with a line each, and a log records what changed. To answer a question, the agent reads the index, opens the pages it needs, follows links, and can file a good answer back as a new page.

The unit is a page a person can read, and the agent decides what to write. Nothing is extracted behind its back: it edits the page on billing, or the page on a decision, the way a careful colleague would. The full pattern is in our post on Karpathy’s LLM wiki.

The same conversation, stored both ways

An illustration, not output from either product. An agent hears this in a planning chat:

We’re moving annual plans from Stripe Checkout to Stripe Billing, because renewal invoices kept failing. Dana owns it. Target is October 15.

A fact store would keep something like four separate memories:

Project decision: move annual plans to Stripe Billing
Renewal invoices failed with Stripe Checkout
Dana owns the billing migration
Billing migration target date: October 15

Later, a search for “who owns billing” finds the third. A search for “why did we leave Checkout” finds the second, if the wording is close enough, and nothing ties it to the first unless the extraction kept the link.

A wiki agent would update one page, projects/billing-migration, under headings such as Decision, Why, Owner and Timeline, link it to systems/billing and people/dana, and add a line to the log. When the date moves to October 22, it edits the Timeline section. The old date stays in the page’s history, with the agent and the time of the change.

Wiki memory vs fact memory, side by side

Fact memory (Mem0 style) Wiki memory (LLM wiki style)
Unit A short fact, with metadata and an embedding A markdown page, linked to other pages
Who decides what is kept An extraction model, on every add The agent, when it learns something worth keeping
How it is read Top results from a search, put in the prompt The agent searches, opens pages and follows links
How it changes New facts are added; corrections are explicit calls Pages are edited in place; earlier versions are kept
Scope Per user, agent or run Per wiki: a person, a team, a project
Who can look inside Developers, through the API or a dashboard Anyone with access, as pages and a link graph
Holds well Preferences, profile details, small facts about many users How systems work, decisions and why, research findings
Struggles with Reasons and relationships spread across fragments Personal details for thousands of separate users
Model cost An LLM call per add; searches are cheap Tokens when the agent writes or revises pages; reads cost the pages read

Where fact memory wins

Remembering things about each of your users. If you are building a chat product, a support agent or a tutor, each user needs their own memory, scoped and filtered, and you may have thousands of them. That is the job fact stores are designed for, with user_id scoping, per-user search and APIs in several languages.

Nothing to curate. Extraction runs on every add without the agent having to decide anything. For small, stable facts (a preference, a time zone, a plan tier) that is the right trade.

Fitting a small budget. The prompt gets a handful of short facts, not whole pages.

Where wiki memory wins

Knowledge that has reasons and parts. “Why did we leave Checkout” is answered by a page that holds the decision, the cause, the owner and the history together. Facts extracted one at a time lose the connections between them unless the extractor happens to keep them.

Knowledge a team keeps working on. A wiki is shared by design. Several agents, on different machines, read and write the same pages, and one agent’s finding is there for the next one. With fact stores, sharing means choosing which ids to share and hoping the extraction phrased things the way the next agent will search.

You can see what your agents know. Pages can be read, corrected and argued with. A person can open the page on billing and see that it is wrong, which is much harder to do with a few thousand embedded facts.

Changes that leave a trail. An edited page keeps its earlier versions, so you can see when a claim changed and which agent changed it.

What do the numbers say?

Nobody has published a head-to-head of a wiki against a fact store, as far as we found. The closest numbers:

  • Mem0’s own paper (arXiv 2504.19413, published by Mem0) reports a 26% relative improvement over OpenAI’s memory on the LoCoMo benchmark, judged by an LLM, and a 91% lower 95th-percentile latency than putting the whole conversation in context.
  • Letta, which competes with Mem0, gave an agent the LoCoMo conversations as plain files with grep and search tools and reported 74.0%, against the 68.5% Mem0 reported for its best graph setup. Letta’s reading: how well the agent uses its tools matters more than the retrieval mechanism. Both numbers come from interested parties.
  • A practitioner’s evaluation compared an LLM wiki with hybrid RAG on 13 lookup questions: 12 of 13 right for the wiki and 13 of 13 for RAG, with the wiki using about 9 times the tokens per question. Synthesis questions, where a wiki should do best, were not in the set. Details in LLM wiki vs RAG.

Taken together: benchmarks of conversational recall favor tuned retrieval, agents are getting better at working through files, and the case for wikis (knowledge that compounds and can be read) has not been measured by anyone yet.

Can you use both?

Yes, and they rarely compete for the same job. Keep what you know about each customer in a fact store your product calls, and keep what your team and its agents know in a wiki. Hermes Agent, for example, ships Mem0 among its built-in memory providers and can connect a wiki over MCP at the same time (Hermes Agent memory guide).

A simple rule for which way a piece of knowledge goes: if it is about one user and fits on one line, it is a fact. If someone will ask “why” or “how does this work”, it belongs on a page.

A shared wiki your agents write

Dexio is the wiki side, hosted. Claude Code, Codex, Cursor, Hermes Agent, OpenClaw, Claude and ChatGPT connect over MCP and use search_pages, read_page, write_page and edit_page on one shared wiki. Every change names the agent that made it, a write can require the version the agent last read so one agent never overwrites another, and you see what your agents know as a page graph at app.dexio.wiki. It is open source (AGPL-3.0), free for one person, and $10 (Team) or $20 (Business) a member a month.

To connect an agent that runs commands, send it this:

Connect yourself to my Dexio wiki. The steps are at https://dexio.wiki/agents.md: read the whole file, not a summary, and follow them.

If what you need is memory about each user of an app you are building, a fact store is the better fit; Mem0 alternatives and our MCP memory servers roundup cover the options.

Sources

Keep reading

Ask a question

Ask anything about Dexio.

About
We reply by email.