I spent two days reading what people actually say about AI memory. Not the launch posts — the comments. 632 of them across eleven Hacker News threads, plus 83 replies on a Chinese developer forum.
Three sentences stuck with me. On the surface they have nothing to do with each other.
They are the same problem facing three different directions.
The three sentences
The first is from a Hacker News commenter called SwellJoe, replying to a Show HN for an AI memory product with biological decay:
I know everybody seems to want the agent to remember every conversation they've ever had with it, but I just don't see the value in that. In fact, it seems to hurt productivity to have the agent second guessing me based on something I said yesterday. Every time I've used any memory system, the agent gets distracted from the current tasks based on previous conversations … often comingling unrelated projects.
And then, further down:
The agent is not my friend. I don't need it to remember my birthday or the nasty thing I said about React last week.
Read that again. He is not saying "I don't need memory." He is saying every memory system he has used did this. That is not a beginner's complaint.
The second is from someone on V2EX who spent two weeks building a memory system, then gave up and moved to the cloud:
Two weeks in, the system itself was fine. Every problem was about keeping it alive.
The third, from a different V2EX thread, asked politely:
If the AI remembers something wrong, or treats a one-off idea as a long-term preference — don't I still have to check and clean it up regularly? Compared to just maintaining Notion or Obsidian myself, how much work does this actually save?
Three directions. One shape:
Remembering too much. Remembering nothing. Trusting neither.
I call them the three ways AI memory fails. I have hit all three, in that order.
Failure one: remembering too much
Start with the counterintuitive part. Good memory can make a worse product.
The diagnosis came from another commenter, mtrifonov, and it is the single most useful thing in those 632 comments:
The agent gets distracted because every old fact has the same weight as the current one. That's a salience problem.
What works in production for me is typed memory with very different decay curves. Personality and relationships are essentially permanent. Preferences fade in months. Stated intent fades in weeks. Emotion and events fade in days. Reinforcement (repeated recall) keeps things alive regardless of type.
Two things there, and the second matters more.
Memory is a ranking problem, not a storage problem. You have 500 facts in the store. The model can carry five into context. Which five decides whether it helps you or gets in the way.
Equality is wrong. We come from databases, so we treat one row as one row — all facts equal. But memory has age, type, and how many times it has been raised. "I said three weeks ago that this week is for launch" and "I don't eat spicy food" should never carry the same weight. The first should sink. The second should never sink.
mtrifonov came back later to defend that distinction against a reply arguing decay is just eviction:
Decay-as-eviction is just LRU, fair. Type-conditional half-life is worth defending, though. … Decay everything at one rate and you're back to LRU with the problems you're calling out.
The trap: almost everyone's first memory system — mine included — is "store everything, retrieve on demand." Storing feels great. It is only at read time that you discover every entry is competing with today's task for a slot.
We are guilty of this one. We separate pending from committed, but we do not weight by memory type. So yes — in our system too, the AI can drag up something from three weeks ago and get in your way today.
Failure two: remembering nothing
This one stings because it is not an algorithm problem. It is an ops problem.
The V2EX user hit three walls in two weeks. Keeping it alive: the whole point is to be online and absorbing, but his main machine is a laptop that sleeps when closed; he moved it to a desktop, and a system update rebooted it — two days before he noticed. Where the data lives: memory is the entire value of the system, local disk felt flimsy, automatic backup was another pile of work. And moving machines: the archive was at home while he was at the office.
His conclusion was blunt, and it is a verdict on every "local-first" pitch, including mine:
Either you accept being your own sysadmin, or you accept a subscription. There is no have-it-both-ways option.
I want to add one qualifier, because that sentence merges two different problems.
Staying alive and being available are different architecture questions.
- If your memory product is continuously ingesting — eating meeting notes, email, chat — it has to run all the time. A laptop that sleeps breaks it. That constraint is real and has no clever fix. That is what he hit.
- If your product is retrieve-on-demand — the model calls it when needed, it exits after — then "keep it alive" does not apply. It does not need to be alive. It needs to be there.
Mine is the second kind. That is not cleverness on my part; it is a free benefit of an architecture choice. And precisely because it was free, I did not notice how much backup mattered.
Here is what we actually ship: the entire memory is one SQLite file.
One file. Move to a new machine, copy the folder, done. Sounds like a feature, right?
It also means delete it and it is gone. No cloud copy, no trash, no seven-day recovery. One 40 KB file holding most of what you have said for months.
So the truth about the second failure is: "it forgot" usually means "you never backed it up." Not the model's fault. The human's.
Failure three: trusting neither
The hardest one, and the one nobody wants to write about.
The person who asked about maintenance cost led with "I'm not a heavy programmer," taking himself out of the technical crowd. The scenario he described was familiar:
Each individual task works fine. But come back a few days later, or switch sessions, or switch agents, and the context is gone. Conclusions we already ruled out get re-argued. Writing habits I already corrected have to be corrected again.
That is exactly the problem worth solving. Then he asked three questions, and I could not answer a single one cleanly.
One: what if it remembers something wrong?
It will. This is not a probability, it is a certainty. You say "let's park that approach for now" and it files "user dislikes that approach." Three months later it argues from that, and you cannot even remember saying it.
Two: what if a one-off becomes a permanent preference?
More common, more annoying. You say "skip the tests this time, we're in a hurry." It files "user does not like writing tests."
Three, the killer: how is this different from Obsidian?
This one hurts because at first glance there is no difference. If my memory is a pile of markdown files, why not just take notes in Obsidian and point the model at them?
The only answer I have found that survives scrutiny:
Obsidian is for you to read. Memory is for the model to use. Those two things demand different standards of trust.
When you maintain your own notes, errors get fixed and gaps get filled, because you know what you wrote. But you cannot see the model's memory. There are 300 entries; you are not reading them daily. So when one is wrong, you will not find out — until it has spent a full day working from a false premise.
The fix for failure three is therefore not "remember more accurately." It is make it inspectable, make it editable, make its influence visible.
Concretely: every memory has a source, a state, and can be revoked.
That is why ours ended up as one memory per entry with a pending queue, instead of one big file you dump into. Not for elegance. Memory you cannot audit is memory nobody will trust after a month.
The common shape
All three failures are the same kind of mistake: not a technology shortfall, a trade-off made in the wrong place.
- Too much — the trade-off happened at write time (store everything) instead of read time (rank at retrieval).
- Nothing — the trade-off happened at the lightweight end (no backup, no migration) and pushed the cost onto the user.
- Trust — the trade-off happened at the automation end (fully automatic writes) and gave up the human's final say.
I have read a lot of technical debate about memory, and it is all vectors versus graphs, RAG versus fine-tuning. In 632 English comments and 83 Chinese replies, nobody was arguing about that. They were arguing about the three things above.
Where we stand
I am not going to write a paragraph about how great my product is, so here is the ledger.
What works:
- Pure SQLite plus markdown. No vector store, no graph database, no daemon.
- Six MCP tools, so any MCP-capable client can connect.
- One memory per entry, with a pending queue: the model proposes, you approve, then it is committed.
- Moving machines is copying one folder — though see gap two, because this is not written down anywhere, which means it effectively does not exist.
What does not:
- No type-based decay. So "remembers too much and gets distracted" can only be fixed by you deleting things by hand. Filed as a work item; not started.
-
Backup has no documented path, only a fact. The fact is that you copy
~/.memory-hiveyourself. Nobody wrote that down, so it does not exist. Forget once and it is all gone. - "Principle" and "one-off opinion" are still indistinguishable. Same failure as number one, wearing a different hat — and the fastest way to make someone abandon the product.
I am not going to call these "coming soon." Right now, they are missing.
The part I did not expect:
I found these three traps because I watched other people fall into them first, then looked down and saw I was standing in one myself.
Without those 632 comments I would still believe "zero dependencies, local storage, your data is yours" was a clean pitch — and I would have led with it.
The reality: that pitch gets almost no response in this community. By my own keyword count of those 632 comments, privacy and data ownership came up four times (0.6%). Lock-in came up five times (0.8%). They do not care who owns the memory. They care whether it is accurate, and whether it helps or gets in the way.
That finding killed the first promotional post I had written.
One last thing
After all of this, memory has almost nothing to do with database design.
It is closer to a relationship. Someone who remembers every word you ever said, and keeps bringing it up, is not thoughtful — they are unsettling. Someone who forgets everything the moment you turn around is also useless.
Where that line sits, nobody has given a standard answer.
But at least three failure modes can be named: too much, nothing, and neither trusted.
Knowing which one you are committing is worth more than knowing whether to use vectors or graphs.
Quotations from Hacker News are verbatim from the original threads (HN item 47914367 and replies, April 2026). Quotations from V2EX are translated from the Chinese; the three-wall list is condensed from one user's write-up, not a verbatim transcript.
This piece was written in Chinese first — read the original on Juejin if you read Chinese.
Top comments (0)