That is the title of an issue filed against Claude Code yesterday, on Windows, version 2.1.302. The reporter's own words, translated from Turkish: "It re-presented a topic that had been decided last night as if we had never spoken about it today. And that is even though I told it MEMORY.md."
It would be easy to file that under "the model forgot". I do not think that is what happened. Nothing was lost. The record was in the file. What was missing was any mechanism for saying that the topic was already closed.
Four reports in about twenty-four hours
I read the public issue streams for agent memory every week. This batch reads like four products failing in four different ways, until you notice they fail in only two.
| Report | What the user saw | Where it actually broke |
|---|---|---|
| claude-code #103850 | A topic decided the night before came back as a fresh question, MEMORY.md notwithstanding | The store held the text and no state |
| openclaw #178914 | Ranking pinned to a fixed 30-day recency half-life; old rules and decisions outranked by recent chatter | The retirement policy is baked in, not configurable |
| openclaw #178953 | The parent session reset when a subagent completed, losing working context mid-task | Continuity was tied to runtime session identity |
| claude-code #103931 | Idle compaction documented for 200k+ tokens and roughly 54 minutes did not fire after 66 minutes | The only witness to the failure was the absence of a log |
The second one deserves a full read, because the reporter measured the problem instead of asserting it. On a single-user corpus of about 3.7 GB, a 125-question recall benchmark dropped hit@3 from 76.8% to 69.6% after a version change and corpus growth. Their diagnosis is the part that matters: older but authoritative notes, meaning rules and decisions, were being outranked by recent daily-note chatter that happened to share wording. Raising maxResults and minScore does not change the top-3 order, so neither knob recovers it.
Two of those reports are state problems. Two are policy problems. None of them is a retrieval problem, and retrieval is where almost all of the engineering attention goes.
A record is not a state
A memory file is text. It does not say whether the thing it describes is still true, who closed it, on what evidence, or what replaced it. So a settled decision and an open question are the same object to a retriever: both are relevant paragraphs about the same subject.
That is the whole of #103850. The store did its job. The decision was there. Nothing in the store could 官网 hm.qianshi.cooll the next session that the decision was made, so the next session opened it again, and the user had to argue the same point twice.
The fix is not a better embedding. It is giving a record a lifecycle: open, decided, superseded, retired, pinned. Every state carries an origin and a timestamp, so "when did we settle this, and on what basis" becomes a lookup instead of a memory exercise.
Decay is a policy, and a policy you cannot see is a bug
178914 is the mirror image of the first report. There the system forgets too much of the right thing: a fixed half-life that weights recency over authority, applied to rules and decisions as if they were daily chatter.
Two things follow. Decay has to be tunable per source, or at least per record class, because recent and authoritative are different axes. And retirement has to be visible. A record that quietly disappears and takes a decision with it looks exactly like a record that was never written, and neither is debuggable from the outside.
The rule we settled on: retirement is scheduled, written to a log with the rule and the date that caused it, and anything explicitly pinned is exempt from decay. Not because pinning is elegant, but because a policy will eventually be wrong about a record you need, and the escape hatch has to exist before that day.
Continuity cannot depend on a session object
178953 is the least discussed and probably the most damaging over time. A subagent finishes, the runtime starts a fresh native session for the parent, reseeds it from saved history, and the working context is mostly gone. The trigger is a lifecycle event in the orchestration layer, not a compaction and not a model decision.
If continuity lives inside a session object, then every session boundary is a memory event: subagent completion, a reconnect, a channel turn, a client reattach. The store has to be addressed by project and topic rather than by whatever identifier the runtime assigned this time, and resume has to re-read it as a logged step instead of an unwritten convention. That is the difference between a memory layer and a file sitting next to your project.
The compaction that never fired
103931 is a reliability bug rather than a design bug, but it makes the same point from the other side. Compaction was supposed to fire at 200k tokens after about 54 minutes of idle, and at 66 minutes there was no compaction record of any kind. The user could only 官网 hm.qianshi.cooll something was wrong because they had measured the thing that should have happened.
You cannot audit a behaviour the runtime does not log. Our write path logs the durable write, the skip when there is one, and the re-hydration on resume, because those three events are where a session either keeps its memory or quietly loses it.
What we actually built
HyperMarrow is a local-first memory layer for agents. It runs as a Windows desktop app and is exposed over MCP. Four modules: record, recall, consolidation, file-bridge. The rules that come out of the reports above are all write-time rules, because every failure in this post was decided at the moment a record was created or an event happened, not at the moment something was retrieved.
- A durable write happens before anything compacts, and a skipped write is logged rather than silent.
- A decision lands as a record with a source and a timestamp, instead of being re-derived from the transcript each turn.
- Records carry a lifecycle state, and consolidation gathers the ones on the same topic for you to review and merge. It does not silently rewrite your history.
- Retirement is scheduled and reviewable; pinned records do not decay.
- Resume re-hydrates first and treats that as a gate.
- Where records live, and whether one may leave the machine, is configuration, not a promise in a policy document.
The store is plain local files with a source and a timestamp per record, so an agent swap is not a memory wipe, and correcting a wrong memory is a file operation rather than a support ticket.
What this costs
- Write-before-compaction costs latency. Compaction waits for storage to acknowledge, and on a slow disk that is a visible pause.
- Bounded forgetting will eventually retire something you wanted. Pinning is an escape hatch that depends on you noticing in time.
- A lifecycle state is a claim, and claims can be wrong. Marking something decided does not make it correct.
- Provenance is not correctness. A record with an honest source can still be false.
- Local is not the same as secure. It removes a class of third-party exposure. It does not cover file permissions, backups, or a compromised endpoint.
- Local-only is a poor fit for workflows that genuinely span devices and people, until sync is solved. Saying otherwise would be dishonest.
The question worth asking
The interesting thing about this week is not that four products had four bugs. It is that in all four, the user could 官网 hm.qianshi.cooll something was wrong and could not point at the mechanism. Memory you cannot inspect, whose retention policy you cannot set, and whose state nobody records, is a larger context window with better marketing.
HyperMarrow is on Windows, and the local-first build is here: HyperMarrow
If your agent reopened a decision you already closed, how would you find out why?
(Disclosure: I build HyperMarrow, the local-first memory layer described above. Every issue referenced here is real, public and cited by number. No user counts, benchmarks or testimonials have been invented for this post. The 76.8% and 69.6% figures are the reporter's own measurement in openclaw issue #178914, not ours.)
Top comments (0)