A typical workflow of an AI memory plugin goes like this: it analyzes your conversation, splits it into 1,000 fragmented snippets, and stuffs them into a vector database. Every time you send a prompt, it retrieves the 5 most similar snippets and appends them to your input. If the agent still can't figure things out, it does another manual search round. This whole setup is called "memory".

Does this sound familiar? Almost every memory plugin works this way:

1. Parse conversation history

2. Generate fragmented "memory" snippets

3. Store them in a RAG database

4. Retrieve the Top 5 most relevant results and inject them into every prompt

5. Still not enough? Give the agent a search tool to look through the history on its own

Some take a more complex approach: they layer long-term and short-term memory, add a background daemon to deduplicate entries, have a "dreamer" process that rewrites memory overnight, and add a reranker. Plugins burn through tons of tokens patching this architecture, but it remains flawed at its core.

A blogger published a long article on liao.gg with a straightforward title: *Agents Don't Need Memory. They Need Documentation.* He listed a whole host of problems with the current approach:

- Similarity search only cares about how close your query is to existing vectors, it doesn't care which entry is correct, up-to-date, or missing.

- Memory fragments are stripped of their original context; motivations, circumstances, and lessons learned are all lost.

- Everything from the past is treated as fact. Code changes every day — how many of those 500 fragments about authentication are still accurate?

- Agents don't know what they don't know, so they'll never think to search for it.

- Ten thousand embeddings just sit there in SQLite. Which ones are outdated? Which ones have never been retrieved? Which ones are quietly leading the agent astray?

His conclusion: The entire memory plugin ecosystem is solving the wrong problem. It's time to switch to a different approach — documentation.

When people write code, they don't dig through conference recordings from three years ago. We write things down, then look them up when we need them. Agents work the same way: give them a readable and writable Markdown workspace that contains instructions, specifications, decisions, and indexes. They look up relevant information before starting work, update outdated content after finishing, and write down new conclusions. The work cycle changes from "Prompt → Build → Forget" to "Prompt → Consult → Build → Update". No vector databases, no embeddings, no bunch of background processes. You can directly read, edit, commit, and share every document with your team.

The blogger says he has been using this approach for a year, and has open-sourced a plugin called Operator Memory.

However, after this tweet was posted, it sparked a heated debate in the comments section. Game developer Mario Zechner commented when retweeting:

> Worth a read, but I still disagree. For code, neither memory nor documentation is efficient. Your codebase is all you need. Keep it modular, keep modules small, and at most maintain a small map to point you in the right direction.

Some agreed: "The codebase is the map, but agents keep asking where the map is."

Some opposed: "Documentation and comments go out of date so quickly, they're seriously misleading."

Replying to a comment saying "agents aren't good at writing modular code", Mario said: "They actually can do it if you tell them clearly what to do."

Another commenter pointed out: "Most knowledge work doesn't even have a codebase; traces of work are scattered across a dozen different websites, so memory plugins end up doing the job that a repository should do."

That actually gets to the core of the issue. For pure code projects, documentation can be condensed into just a lightweight map. But for context that can't be expressed in code — user preferences, product decisions, cross-system dependencies — a maintainable documentation space is almost certainly more reliable than scraping conversation history.

At their core, memory plugins fight against "forgetting". Documentation doesn't do that. Documentation is written for the future; it only records the conclusions worth keeping right now. If an agent has documentation, at least you can review what it knows. For those ten thousand embeddings, you can't even figure out where they went wrong.

Image: A control flow diagram, with "Prompt → Build → Forget" on the left and "Prompt → Consult → Build → Update" on the right.


The discussion is still ongoing. There's no standard answer to this debate, but at least it forces us to rethink one question: What exactly do you want your agent to remember?

Is it old chat logs, or the facts of your current project?

(Original article: