What if the agent that keeps forgetting your project isn’t broken at all, and the memory plugin you bolted on last month is actually solving a problem you don’t have?
I’ve been testing agent tooling long enough to notice a pattern: when an agent fumbles, the first instinct is to give it a longer leash on the past. Add a vector store. Add a memory layer. Add something that scrapes your old chats and tries to reconstruct what you meant three weeks ago. And then the agent still writes code that ignores your conventions, still proposes an architecture you rejected in session two, still asks you where the auth logic lives.
An essay published October 3, 2026 on explainx.ai put the argument plainly, and it’s been bouncing around ever since: 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. Those are not the same thing, and conflating them is why so much memory tooling feels like a demo that never graduates.
Conversations Are Not Specs
Think about what’s actually in your chat history. Half-formed ideas. Approaches you abandoned. Debugging tangents. A decision you made and then quietly reversed. If an agent faithfully recalls all of that, it’s recalling noise alongside signal with no way to tell which is which.
Kevin Liao’s post on the same theme hit the front page of Hacker News, and his framing is the part I keep coming back to. A single file isn’t enough. The agent needs an entire brain, a structured workspace where it can record instructions, specs, decisions, research, indexes, anything, without being asked. That last clause is the whole ballgame. Not a file you remember to update. A workspace the agent maintains as a byproduct of working.
Documentation has a property that conversation history doesn’t: it’s been edited. Someone decided what mattered. A spec is a conversation that got resolved. A decision record is an argument that ended. When an agent reads those, it inherits the conclusion instead of relitigating the debate.
The Counterargument Deserves a Hearing
I’d be doing you a disservice if I pretended this was settled. Oracle’s engineering blog makes a case I can’t dismiss. Their position is that many agents need to remember more than the latest user message. They need preferences, decisions, task state, policy guidance, tool outputs, and prior conversation context. Without memory, an agent starts cold every time.
Eric Roby, writing about how the 2026 agent stack fits together, draws a line that I find more useful than either absolutist take. A single-session chatbot doesn’t need memory. But track user preferences over time when agents cover multiple sessions, and gather project context over weeks, and the calculus changes.
Read those three sources together and the disagreement looks smaller than the headlines suggest. Oracle’s list, preferences, decisions, task state, policy guidance, is a list of things that want to be written down somewhere durable and queryable. Call that memory if you like. Liao calls it a structured workspace. The implementation differs more than the intent does.
What This Means for Your Tool Choices
Here’s where I land as someone who installs these things and then has to live with them.
- Be suspicious of memory as a feature bullet. If a tool advertises memory without telling you what gets stored, how it’s structured, and how you correct it, you’re buying a black box that will confidently misremember.
- Prefer tools that write files you can read. Markdown in your repo beats embeddings in someone’s hosted index. You can review it, diff it, and delete the wrong parts.
- Ask whether the agent maintains docs unprompted. Documentation that depends on your discipline will rot. The useful version writes itself as work happens.
- Match the tool to the session shape. Single-session work genuinely doesn’t need persistence. Multi-week project work does. Paying for the heavy option on the light use case is just overhead.
The memory-versus-documentation framing is a good provocation, and I think the docs camp has the stronger practical argument right now, mostly because their artifacts are inspectable and the memory layer’s artifacts usually aren’t. But treating it as a binary misses what both camps are circling: agents need durable, structured, correctable project knowledge. The question isn’t whether to store context. It’s whether you can open the file and see what your agent thinks it knows.
Test that before you commit. Ask your agent what it remembers about your project, then go find where that lives on disk. If you can’t, you don’t have documentation. You have a guess with good manners.
đź•’ Published: