Kevin Liao’s blog post says agents don’t need memory, they need documentation. Oracle’s developer blog says many agents need to remember more than the latest user message, including preferences, decisions, task state, policy guidance, tool outputs, and prior conversation context. Both of these are live, both are being shared, and both are describing the same category of software.
That contradiction isn’t a mistake. It’s the whole story.
What the memory crowd is actually selling
I’ve reviewed enough agent tools to recognize the pattern. A product ships, it feels dumb on the second session, and the fix that gets bolted on is a memory layer. Store the conversation, embed it, retrieve it later. The pitch writes itself: your agent will remember you.
The essay from explainx.ai, published October 3, 2026, makes the sharpest version of the counterargument. It says this is the wrong problem to solve. You don’t want an agent that remembers your conversations. You want an agent that understands your project.
Read that twice, because the distinction is doing real work. Remembering a conversation and understanding a system are not the same capability. One is a transcript. The other is a model of how things fit together, why decisions were made, and what breaks if you change them. A memory plugin that recalls you once said “use Postgres” is not the same as a document explaining your schema, your migration policy, and the three times someone tried to normalize the users table and regretted it.
Documentation as the agent’s actual workspace
Liao’s framing is the part I keep coming back to. He argues a single file isn’t enough. The agent needs an entire brain, a structured workspace where it can record instructions, specs, decisions, research, and indexes without being asked.
Without being asked. That’s the load-bearing phrase. Most teams treat documentation as something a human writes for other humans, occasionally, under duress, usually after the decision is already forgotten. The version Liao describes is different: the agent writes its own reference material as a side effect of working, and that material becomes the context for the next run.
This has properties a memory store doesn’t:
- You can read it. A vector database is opaque. A markdown file in your repo is not. When the agent does something stupid, you can open the file and see exactly which bad assumption it was operating on.
- You can edit it. Correcting a memory layer usually means hoping your new statement outranks the old one in retrieval. Correcting a document means deleting a line.
- It’s shared. Memory is per-agent and per-user. Documentation sits in the project where every agent, and every teammate, hits the same source of truth.
- It survives tool churn. Switch agent frameworks next quarter and your memory store is landfill. Your docs directory moves over untouched.
Where the memory people have a point
I’m not going to pretend this debate is settled, because the sources don’t settle it. Eric Roby’s piece on the 2026 agent stack draws a line I find hard to argue with: a single-session chatbot doesn’t need memory, but you want to track user preferences over time when agents work across multiple sessions, and gather project context over weeks.
Oracle’s position lands in similar territory, listing the things agents need to carry forward beyond the last message. And honestly, some of those items are a poor fit for a document. Task state is a good example. “Which of these 400 records have I already processed” is not a design decision worth writing an architecture note about. It’s bookkeeping, and bookkeeping wants a database.
So the honest read is that two different problems got collapsed into one word. Durable project understanding, which belongs in documentation your team can see and fix. And operational state plus per-user preference, which belongs in storage. Calling both of them “memory” is how you end up buying a retrieval system to solve a writing problem.
What I’d check before paying for a memory feature
My tooling bias, stated plainly: if a vendor’s answer to “how does your agent understand my codebase” is a memory add-on, I get skeptical fast. Ask whether the agent reads and writes files in your project. Ask whether you can inspect what it believes and correct it in one place. Ask what happens when a teammate runs the same agent on the same repo.
If the only answer is an embedding store you can’t open, you’re not buying understanding. You’re buying a chat log with better search.
The sources disagree on the headline, but they point the same direction underneath. Agents fail because nobody wrote down how the project works, not because they forgot what you said last Tuesday. Fix the first problem and the second one gets a lot less interesting.
🕒 Published: