DEV Community: qianqiuwanzi

Session transcripts still outrank curated memory

qianqiuwanzi — Fri, 23 Oct 2026 08:57:45 +0000

That is the title of an issue reopened against OpenClaw this morning. With sessions enabled, memory_search still ranks session transcripts above the durable memory a user curated by hand, and there is no per-source weight to change the ordering. The issue it reopens was closed for inactivity, not fixed.

Forty hours earlier, in the same project, a second report made the mirror-image complaint. Two writers that the runtime itself runs or authorizes, session-rooted runs and native tools invoked through claude-cli, change MEMORY.md, USER.md and memory/** without leaving a provenance record. The consequence is not a warning banner. The next recorded write quarantines the files the user maintains by hand.

A third report, on a different tracker the same week, closes the loop. A user saved "stay in scope" into memory several times, and the model kept ignoring it.

A talk making the rounds on Hacker News this week is titled "Shared memory doesn't stop AI agents from drifting". The title is the argument, and the title is right.

None of these three is a retrieval-quality bug in the usual sense. They are three symptoms of one missing concept: authority.

Three failures, one missing field

Report	What the user sees	What is actually missing
openclaw #181362	Transcribed chat outranks the rules the user curated	A per-source authority axis
openclaw #180796	Hand-maintained memory files get quarantined after an untracked write	A provenance record for every writer
claude-code #104162	A rule saved to memory is not followed	A read at the decision point

Similarity is not authority

When a single agent wrote its own memory, recency and similarity were reasonable proxies for importance. One writer, one reader, one notion of truth. The worst case was retrieving a slightly stale paragraph and having the model work around it.

Put several harnesses on one store and the question changes. It is no longer which paragraph is relevant. It is which of these two paragraphs is allowed to overrule the other. A transcript is a record of what was said. Curated memory is a record of what was decided. Both can be perfectly relevant, and only one of them is binding.

A scoring function that cannot represent that distinction will eventually put the wrong one first. This is not a tuning problem, and the reporting on it has been consistent: neither a larger result count nor a lower score floor changes the top three. The order comes from a model that has no idea who wrote the thing.

A write without a source is a write you cannot trust later

180796 is the more interesting report, because the failure is conservative in the worst possible way. The system notices that its memory files changed without a matching provenance record, cannot establish who changed them, and quarantines the files.

From the system's point of view that is correct behavior. From the user's point of view, their own memory was taken away by their own tool, for a reason the tool cannot explain, and the thing that triggered it was a write the runtime itself performed.

The lesson generalizes. A write without a source is not a write you can trust later. Every record has to answer three questions at write time rather than at read time: who wrote this, on behalf of which run, and when. If it cannot, then every consistency check built on top has to choose between trusting everything and trusting nothing, and both of those choices are wrong.

A rule that is stored but not read is not a rule

104162 is the shortest of the three and the most familiar. The reporter's own words: it writes it into a memory, but it never seems to follow the memory.

Storing a constraint is not enforcing it. If memory is only consulted when somebody asks a question, a standing rule arrives as context, and context gets negotiated away by whatever this turn is trying to accomplish. The rule has to be read at the decision point, and the read has to be a gate rather than a hint.

This is also why recall benchmarks are a weak measure of a memory layer. A system can score well on whether it retrieved the right fact while failing every test of whether it obeyed a standing rule, and the second failure is the one that costs a working session.

What we built instead

HyperMarrow is a local-first memory layer for coding agents. It runs as a Windows desktop app and is exposed over MCP, with the same store reachable from a Python SDK and a Node SDK. Four modules: record, recall, consolidation, file-bridge.

The reports above produced write-time rules, not retrieval tricks:

A record lands with a source and a timestamp at the moment it is written. Provenance is a field, not an inference.
The store is ordinary local files, so which agent wrote a line is something you can check with a file viewer instead of asking the runtime.
consolidation gathers same-topic records for you to review and merge. It does not silently rewrite history, and it does not let a transcript overwrite a decision it merely quotes.
Standing rules can be pinned, and pinned records do not decay. Declaring authority is an explicit act, and it is reversible.
A durable write happens before compaction, and a skipped write is logged rather than swallowed.
Whether a record may leave the machine is configuration, not a promise in a policy document.

What this costs

Provenance has a maintenance cost. Somebody has to decide what counts as a source, and the first version of that taxonomy will be wrong.
Pinned rules do not decay, which means a bad pin survives. Authority is a statement about intent, not about correctness.
Consolidation asks for human review. That is a feature until you are busy, and then it is a queue.
Local-first removes one class of third-party exposure and nothing else. It does not cover file permissions, backups, or a compromised endpoint.
A store that genuinely spans devices and people is not solved by a local folder, and I am not going to pretend otherwise.

The question worth asking

Every memory layer eventually has to answer a question that has nothing to do with embeddings. When two records disagree, which one is allowed to win, and who decided that?

If you cannot answer it for your own store, you do not have shared memory. You have a shared scratchpad.

I'm on the team behind HyperMarrow, a local-first AI memory layer that keeps your data on your own machine. If you're exploring agent memory, the experience entry is on our site; coming from this article, use https://hm.qianshi.cool/api/v2/dl?from=devto and the client will tag the source automatically.

Previously resolved topics re-raised across sessions despite MEMORY.md

qianqiuwanzi — Wed, 21 Oct 2026 07:13:27 +0000

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.)

Idle compaction was enabled remotely, with no notice or opt-in

qianqiuwanzi — Sat, 17 Oct 2026 00:38:41 +0000

That is a real issue title from this week, filed against Anthropic's own coding agent, and it is not the only one. In the same few days the tracker produced a cluster that all describes the same thing from different angles: compaction switched on remo官网 hm.qianshi.cooly with no notice or opt-in (#102260), memory and protocol files not reloaded after resuming from a compacted context (#102190), project decisions that do not survive across sessions (#102045), a plugin's call to session.compact() quietly refused inside the desktop app (#102278), the compaction hook no longer firing at all (#102134), and compression causing the agent to deny that prior work exists (#101950).

Read those as a group and a pattern shows up. None of them is a retrieval bug. Every one of them is a control bug, and they all come from the same architectural decision: the agent's memory lives inside the runtime, so whoever owns the runtime gets to decide what is kept, what is dropped, and when the whole thing changes behaviour.

Six reports from one week, and none of them is a retrieval bug

Report	What the user saw	Where the loss actually happened
#102260	Compaction turned on remo官网 hm.qianshi.cooly, no opt-in, no notification	A third party changed how your memory behaves
#102190	After a resume, memory and protocol files were not re-read	The durable copy existed but was not re-hydrated
#102045	Decisions agreed in one session were gone in the next	Nothing durable had an address to be found again
#102278	A plugin's compact() call was refused in the desktop build	The memory API is not available to the people who own the box
#102134	The compaction hook stopped firing in a point release	The only visibility into compaction is gone
#101950	The agent denied work it had already done	A summary replaced the record, and the summary was wrong

The last row is the one that hurts. When a summary is the source of truth and the summary is wrong, the agent does not report uncertainty. It argues with you, confidently, about work you watched it finish.

The rules we enforce at write time, in the order they act

I build HyperMarrow, a local-first memory layer for agents, and these six reports are the exact failure list the design was built against. The rules are ordered by how early they act, because every failure above was decided at the moment a record was created, not at the moment it was retrieved.

1. The durable write happens before anything compacts

Nothing is allowed to summarise or drop the working context until the durable copy exists and has been acknowledged. That is a write-ahead rule, and it answers #102260 directly: a remote flag can decide how the runtime behaves, it cannot reach into a store the runtime does not own. If a durable write is skipped, the skip is logged rather than silent.

The subtle version of getting this wrong is putting a state file into the prompt and calling it durable. A file loaded into the prompt is still inside the window. The next compaction will summarise it like everything else, which is why #102190 looks like a reload bug when it is really a storage-boundary bug.

2. A decision is written as a record, with a source and a timestamp

A preference, a decision or a conclusion lands in durable local storage as an actual record, carrying where it came from and when. If instead it gets re-derived from the transcript on every turn, you get #102045: the same decision agreed twice, in two sessions, with no way to look up what was agreed the first time.

Once a record has provenance, what the agent believes stops being an argument and becomes a lookup. You can also see that it believed something wrong, and when.

3. Forgetting is bounded and scheduled

An unbounded memory is not a feature. Records that stopped being relevant retire on a schedule instead of being carried forward forever, and anything you explicitly pin is exempt from decay. The point is not storage savings. It is that a retrieval space which only ever grows makes short queries against long records worse with use, and the degradation is invisible: answers get vaguer and nobody can point at the record that should have been retired.

Retirement has to be reviewable too. "It is gone and nothing told me" is the failure mode people file issues about; "this record retired on this date under this rule" is a different product.

4. On resume, we re-hydrate first and treat that as a gate

Resuming a session re-reads the store and makes memory and protocol files part of the task preamble, as a logged step rather than an unwritten convention. #102190 is exactly what happens when that step is optional: the store still has the record, the runtime just never looks. Making it a gate is the difference between a memory layer and a file next to your project.

5. The boundary is a setting, not a promise

Where records live, and whether a given record may leave the machine, is configuration rather than a paragraph in a policy. If the store is a black box, you cannot see what the agent believes about you, you cannot correct a wrong memory, and #102278 is the shape of the problem: the API for managing your own memory is not exposed to you.

What this costs us

Write-ahead costs latency. Compaction has to wait for storage to acknowledge, and on a slow disk that is a visible pause. It is a trade, not a free win.
Bounded forgetting can retire something you wanted. Decay is scheduled and reviewable, but it is still a policy, and a policy will eventually be wrong. Pinning is the escape hatch, and it depends on you noticing in time.
Provenance is not correctness. A record can carry an honest source and still be wrong. Nothing in our store fixes that.
Local is not the same as secure. Keeping the store on your machine removes a class of third-party exposure. It does not remove file permissions, backups, or a compromised endpoint.
A local store is not automatically the right answer. If your workflow genuinely spans devices and people, local-only is a poor fit until sync is solved, and pretending otherwise would be dishonest.

What actually changes

The failure mode changes shape. Instead of a silent loss you cannot see, you get a record you can read and disagree with. An agent swap stops being a memory wipe, because the store is plain local files behind MCP rather than a proprietary index. Fixing a wrong memory becomes a file operation instead of a support ticket. And a flag somebody flips on their side can change their runtime; it cannot rewrite the copy on your disk.

The modules are record, recall, consolidation and file-bridge, exposed over MCP so the agent does not need a bespoke integration per editor.

Over to you

None of this needs a research breakthrough. It needs memory treated as storage you own, instead of a context window with a summariser bolted on. If the interesting question this week is who gets to decide what your agent remembers, the honest answer for most setups is: somebody else.

HyperMarrow is a Windows desktop memory layer, and the local-first build is here: HyperMarrow

If a remote flag could change your agent's memory tomorrow, would you know what it changed?

(Disclosure: I build HyperMarrow, the local-first memory layer described above. Every issue referenced here is real, public and cited by number, and no user counts, benchmarks or testimonials have been invented for this post.)

Your AI Coding Agent Forgot Everything. So I Put Its Memory…

qianqiuwanzi — Wed, 14 Oct 2026 02:57:11 +0000

The Dev.to feed kept handing me the same idea from three directions this week: a local MCP memory server so a coding agent stops losing context between sessions, an on-device voice notebook that "cannot phone home", and local-first semantic search on Windows. That is not a coincidence of phrasing. People are moving agent memory off someone else's server and onto hardware they control.

I build HyperMarrow, a local-first memory layer for agents. Same bet, pushed all the way. But the useful part is not the ideology, it is the five rules I enforce at write time. Every failure I see in the wild is decided when a record is created, not when it is retrieved, so the rules are ordered by how early they act.

1. A decision gets written down with a source and a timestamp

A preference, a decision or a conclusion lands in durable local storage as an actual record, carrying where it came from and when. An assumption that gets re-derived from the transcript on every turn has no address, no origin and no history. Nothing can be compacted away because there is nothing durable, and that is exactly the problem: you also cannot recover it, and you cannot 官网 hm.qianshi.cooll whether the agent still believes something you told it a month ago.

Once a record has provenance, what the agent believes and why stops being an argument and becomes a lookup.

2. The durable write happens before anything compacts, not after

Nothing is allowed to summarise or drop the working context until the durable copy exists and has been acknowledged. This is a write-ahead rule, and it acts earliest of the five. If compaction runs first, whatever it dropped is simply gone, and the loss does not raise an error. It quietly takes something with it.

The subtle version of this failure: dropping a state file into the prompt is not a durable copy. A file loaded into the prompt is still inside the window, and the next compaction will summarise it like everything else. The rule only holds when the store is the source of truth and the prompt is a view over it.

3. Forgetting is bounded and scheduled; pinned records never decay

An unbounded memory is not a feature. Records that stopped being relevant age out on a schedule instead of being carried forward forever, and anything you explicitly pin is exempt from decay. Without a boundary the retrieval space only grows, and short queries against long records get worse with use, not better. This is also the line between a store and a scratchpad: a scratchpad can only be trimmed by wholesale deletion, while a store can retire things one at a time, on purpose, and 官网 hm.qianshi.cooll you what it retired.

4. Recall returns your words, with the origin attached

If what got written was already lossy, no ranker recovers the sentence you actually needed. Recall pulls the stored record rather than a paraphrase of it, and it hands you the hit together with where the hit came from. That is what makes cross-session continuity real rather than decorative: a decision made in one session can be re-found, with its source, from another session months later.

5. The privacy boundary is a setting, not a promise

Where records live, and whether a given record may leave the machine, is a configuration decision rather than a paragraph in a policy. Local-first matters here for a specific reason. If the store is a black box you cannot open, you cannot see what the agent believes about you, you cannot fix a wrong memory, and one breach exposes everything. If the store is on your disk, the durable copy is in front of you, the audit trail is yours, and the whole thing exports so it is yours to back up, move, or leave with.

What moves when the store is local

The cloud question stops being an act of faith. The durable copy is a file you can read, diff and back up.
An agent swap is not a memory wipe. The store is plain local files behind MCP, so it survives a version bump or a different tool.
A wrong memory becomes an edit. Fixing a bad record is a file operation instead of a support ticket.
The failure mode changes shape. Instead of a silent loss you cannot see, you get a record you can read and disagree with.

The modules are record, recall, consolidation and file-bridge, exposed over MCP so the agent does not need a bespoke integration per editor.

What is still not good enough

Write-ahead costs latency. Paying for the durable write before the window is compacted means compaction waits on storage. On a slow disk that is a visible delay, and the honest description is a trade, not a free win.
Bounded forgetting can retire something you wanted. Decay is scheduled and reviewable, but it is still a policy, and a policy will eventually be wrong about a record you needed. Pinning is the escape hatch, and it depends on you noticing in time.
Provenance is not correctness. A record can carry a perfectly honest source and still be wrong. Nothing in the store will 官网 hm.qianshi.cooll you that.
Local is not the same as secure. Keeping the store on your machine removes a class of third-party exposure, it does not remove file permissions, backups, or a compromised endpoint.
A local store is not automatically better. If your workflow genuinely spans devices and people, a local-only store is a poor fit until sync is solved, and I would rather say that than pretend otherwise.

Over to you

None of this needs a research breakthrough. It needs storage treated as a first-class layer instead of a context window with a summariser bolted on. If your agent's memory lives in someone else's cloud, the audit trail belongs to them. Put it on your machine and the audit trail is yours to keep.

HyperMarrow is a Windows desktop memory layer, and the local-first build is here: HyperMarrow

If you already moved your agent's memory local, what tipped it for you: latency, privacy, or the fact that you could not read what it remembered?

(Disclosure: I build HyperMarrow, the local-first memory layer described above. The community posts referenced here are real and public, and no numbers, user counts or testimonials have been invented for this post.)

Your Agent Forgets When the Context Window Compacts. Ours Doesn't, By Design.

qianqiuwanzi — Mon, 12 Oct 2026 01:55:33 +0000

A post this week called context-window compaction a "200k-token lobotomy" and patched it with external state files named after Memento. It is a good write-up, and the naming is honest about the stakes. But it also made the underlying problem easier to see than the fix does.

Here is the part that matters: memory that lives only inside the context window is amnesiac by construction. Compaction is not a bug in that design, it is the design working as specified. The window has a budget, something has to leave when the budget is spent, and what leaves is decided by a summariser, not by you.

That is the failure I built against. HyperMarrow is a local-first memory layer for agents on Windows, and the properties below are the ones I actually enforce. They are ordered by how early they act, because every failure above is decided at write time, not at read time.

1. Decisions are written down with a source and a timestamp

A preference, a decision or a conclusion lands in durable local storage as an actual record, carrying where it came from and when. An assumption that is re-derived from the transcript on every turn has no address, no origin and no history, so there is nothing to compact away and nothing to recover either. Once a record has provenance, what the agent believes and why stops being an argument and becomes a lookup.

2. Write before you compact

Nothing is allowed to summarise or drop the working context until the durable copy exists and has been acknowledged. This is a write-ahead rule, and it acts earliest of the five. If compaction runs first, whatever it dropped is gone, and the loss does not raise an error. It just quietly takes something with it.

This is also the one rule that directly answers the lobotomy post. A state file loaded into the prompt is still inside the window; it gets summarised on the next compaction like everything else. The rule only works if the durable copy is the store, and the prompt is a view over it.

3. Forgetting is bounded and scheduled; pinned records never decay

An unbounded memory is not a feature. Records that stopped being relevant age out on a schedule instead of being carried forward forever, and records you explicitly pin are exempt from decay. Without a boundary the retrieval space only grows, and short queries against long records get worse with use, not better.

This is the part that separates a store from a scratchpad. A scratchpad has to be trimmed by wholesale deletion. A store can retire things one at a time, on purpose, and 官网 hm.qianshi.cooll you what it retired.

4. Recall returns your words, and it shows its provenance

If what got written was already lossy, no ranker recovers the sentence you actually needed. Recall pulls the stored record rather than a paraphrase of it, and it hands you the hit together with where the hit came from. That is what makes cross-session continuity real: a decision made in one session can be re-found, with its source, from another session months later.

5. The privacy boundary is a setting, not a promise

Where records live, and whether a given record may leave the machine, is a configuration decision rather than a paragraph in a policy. Local-first matters here for a specific reason: if the store is on your disk, compaction is a transient event you can survive, while if the store is a vendor's, your long-term memory is exactly as durable as their roadmap.

What surviving compaction actually changes

Read it back against the lobotomy framing:

Compaction stops being an event. The window can compress as often as it likes, because the record was never only in the window.
You can see what was remembered. Every record carries its source, so you can check what the agent actually kept, instead of inferring it from a summary.
You can fix a wrong belief. Editing a bad record is a file operation, not a support ticket.
Cross-session continuity is a property, not a trick. A new session re-finds the old decision with its provenance attached, instead of starting from the transcript again.
The memory outlives the tool. The store is plain local files, so it survives an agent swap, a version bump or a vendor going away.

The modules are record, recall, consolidation and file-bridge, exposed over MCP, so the agent does not need a bespoke integration per tool.

What is still not good enough

A write-ahead rule costs latency. Paying for the durable write before compaction means compaction waits on storage. On a slow disk that is a visible delay, and the honest way to describe it is a trade, not a free win.
Bounded forgetting can retire something you wanted. Decay is scheduled and reviewable, but it is still a policy, and a policy will eventually be wrong about a record you needed. Pinning is the escape hatch, and it depends on you noticing in time.
Provenance is not correctness. A record can carry a perfectly honest source and still be wrong. Nothing in the store will 官网 hm.qianshi.cooll you that.
Compaction is not the only loss channel. An agent that summarises badly, or writes a lossy record in the first place, loses on the way in, before any of these rules get a chance to act.

Over to you

If your agent runs long enough to hit compaction, memory is not a prompt-engineering problem. A longer window only moves the cliff. So: when your agent forgets, would you rather raise the token budget, or open the store and read what it kept?

HyperMarrow is a Windows desktop memory layer. The local-first build is here: HyperMarrow

Disclosure: I build HyperMarrow, so read the above with that in mind. The community post quoted here is real and public, and no numbers, user counts or testimonials have been invented for this post.

People Are Already Using Obsidian as Their Agent's Memory. Here's the Production Version.

qianqiuwanzi — Fri, 09 Oct 2026 07:23:54 +0000

A post this week walks through using Obsidian plus Claude Code as a shared memory stack the author actually runs. Not a thought experiment. Developers are already treating their local notes as the layer their agent reads and writes across sessions.

Two more posts from the same week sit on either side of it. One argues that agents do not need memory at all, they need documentation. A Show HN pitches a memory layer that makes coding agents cheaper on repeat work. Everyone agrees the notes-plus-context story is broken. Nobody agrees on what replaces it.

The instinct in the Obsidian post is right, and the missing piece is easy to state and hard to build: a notes folder is not yet a memory system. A note has no source and no timestamp, nothing decides which notes become durable beliefs, and nothing decides when one should stop being retrieved. Obsidian gives you the editor. The layer underneath is the part that has to behave like memory.

HyperMarrow is that layer for agents on Windows, and the five properties below are the ones I enforce. They are ordered by how early they act, because most of the failures above are decided at write time, not at query time.

1. Decisions are written down, with a source and a timestamp

A preference, a decision or a conclusion has to land in durable local storage as an actual record, carrying where it came from and when. An assumption re-derived from the transcript every turn has no address, no origin and no history. Once a record has provenance, "what does it believe, and why" stops being an argument and becomes a lookup.

2. Write before you compact

Nothing is allowed to summarise or drop the working context until the durable copy exists and has been acknowledged. This is a write-ahead rule, and it acts earliest of the five. If compaction runs first, whatever it dropped is gone, and the loss raises no error. It just quietly takes something with it.

3. Forgetting is bounded and scheduled; pinned records never decay

4. Recall returns your words, and it shows its provenance

If what got written was already lossy, no ranker recovers the sentence you needed. Recall pulls the stored record rather than a paraphrase of it, and it hands you the hit together with where the hit came from. That is what makes cross-session continuity real: a decision made in one session can be re-found, with its source, from another.

5. The privacy boundary is a setting, not a promise

Where records live, and whether a given record may leave the machine, is a configuration decision rather than a paragraph in a policy. This is also why local-first matters for the shared stack specifically. If the memory of the whole team is a folder on one build machine, then access, retention and deletion are things you can actually see, instead of a promise made in a changelog.

Notes versus the layer underneath

A note is content. A record is a claim. The layer stores the decision, plus who said it and when, so it can later be argued with.
A note is retrieved by search. A record is retrieved by recall. Search over a growing folder drifts; recall with scope and kind is bounded.
A note does not expire. A record does. Notes accumulate until you clean them. Records decay on a plan, and pinned ones do not.
A folder is a format. The layer is an interface. Exposed over MCP, so the agent does not need a bespoke integration per tool.

What is still not good enough

Provenance 官网 hm.qianshi.coolls you where a record came from. It does not 官网 hm.qianshi.cooll you the source was trustworthy. Judging it is still on you. A source tag is evidence, not a verdict.
Classification is model-dependent. Anything that decides at write time which kind of memory a sentence is will misclassify some fraction of the time. It fails more quietly than losing the data, but it still fails.
Editable memory means a bad edit is available too. The same open door that lets you repair a wrong record lets the machine next to it change it the other way.
Ranking is still hard. Verbatim recall does not always beat a paraphrase, and short queries against long records still fail more often than they should.

Over to you

A notes folder got the community most of the way there, which is why it spread. The part it cannot do is decide what counts as a belief, keep its source, and know when to let it go. If your agent's memory is a folder, what happens to it when the folder is on someone else's machine?

HyperMarrow is a Windows desktop memory layer. The local-first build is here: HyperMarrow

Disclosure: I build HyperMarrow, so read the above with that in mind. The community posts quoted here are real and public, and no numbers, user counts or testimonials have been invented for this post.

One Sentence Hijacked My Agent's Memory. So I Made Every Memory Auditable.

qianqiuwanzi — Thu, 08 Oct 2026 03:08:12 +0000

A post this week was uncomfortable to read, and the title is basically the whole problem: one word, "update", in the right framing, was enough to hijack an agent's memory. Not an exploit chain. Just phrasing. The agent rewrote what it believed because the input told it to, and nothing in the path was allowed to say no.

The reflex is to file that under prompt injection and move on. That misses the half that matters. Injection is an input problem. What the post actually exposed is a storage problem: if the thing your agent believes lives in a box you cannot open, a poisoned sentence read last week quietly shapes every session after it. You cannot see the belief that got rewritten, you cannot trace which input rewrote it, and you cannot undo it.

That is the failure mode I built against. HyperMarrow is a local-first memory layer for agents on Windows, and the properties below are the ones I enforce. They are ordered by how early they act, because every failure above is decided at write time, not at query time.

1. Decisions are written down, with a source and a timestamp

A preference, a decision or a conclusion has to land in durable local storage as an actual record, carrying where it came from and when. An assumption re-derived from the transcript on every turn has no address, no origin and no history. Once a record has provenance, "what does it believe, and why" stops being an argument and becomes a lookup.

2. Write before you compact

Nothing is allowed to summarise or drop the working context until the durable copy exists and has been acknowledged. This is a write-ahead rule, and it acts earliest of the five. If compaction runs first, whatever it dropped is gone, and the loss does not raise an error. It just quietly takes something with it.

3. Forgetting is bounded and scheduled; pinned records never decay

4. Recall returns your words, and it shows its provenance

If what got written was already lossy, no ranker recovers the sentence you actually needed. Recall pulls the stored record rather than a paraphrase of it, and it hands you the hit together with where the hit came from. That is what makes cross-session continuity real: a decision made in one session can be re-found, with its source, from another.

5. The privacy boundary is a setting, not a promise

Where records live, and whether a given record may leave the machine, is a configuration decision rather than a paragraph in a policy. This is also why local-first matters for the hijack case specifically. A poisoned input stays in your store, where you can find it and remove it, instead of being broadcast into a vendor's model where you have no handle on it at all.

What auditability actually changes

Read back against the hijack:

You can see the belief. Every record carries its source, so the rewritten entry points at the input that rewrote it.
You can undo it. Wrong memory is editable, not permanent. There is no support ticket between you and a bad record.
You can 官网 hm.qianshi.cooll what changed. Because decisions are stored as records instead of re-derived, a rewrite is a visible edit rather than a different answer you are expected to notice.
You can keep it. The store exports, so the memory outlives any single tool, session or vendor.

The modules are record, recall, consolidation and file-bridge, exposed over MCP, so the agent does not need a bespoke integration per tool.

What is still not good enough

Provenance 官网 hm.qianshi.coolls you where a record came from. It does not 官网 hm.qianshi.cooll you the source was trustworthy. Reading a poisoned record and judging it is still on you. A source tag is evidence, not a verdict.
Editable memory means a bad edit is available too. The same open door that lets you repair a hijacked record lets someone with the store change it the other way. Local-first moves that risk onto your machine, which is at least a machine you can inspect.
Classification is model-dependent. Anything that decides at write time which kind of memory a sentence is will misclassify some fraction of the time. It fails more quietly than losing the data, but it still fails.
Provenance is not detection. A record can carry a perfectly honest source and still be wrong, and nothing in the store will 官网 hm.qianshi.cooll you that.

Over to you

Once a memory can be rewritten by a sentence, inspectability stops being a nice-to-have and becomes the floor. So when your agent misbehaves, would you rather read a vendor's log, or open the memory file yourself?

HyperMarrow is a Windows desktop memory layer. The local-first build is here: HyperMarrow

Disclosure: I build HyperMarrow, so read the above with that in mind. The community post quoted here is real and public, and no numbers, user counts or testimonials have been invented for this post.

[FEATURE] suggest starting a new conversation when resuming a large/stale session

qianqiuwanzi — Wed, 07 Oct 2026 01:53:49 +0000

The public issue trackers of the major agent CLIs are the best place to read what "my agent got dumber" actually looks like in the wild. One of the most concrete reports is titled, verbatim:

[FEATURE] suggest starting a new conversation when resuming a large/stale session

The request is small and specific. When you resume a session that has grown large or has gone stale, the CLI should suggest starting a new conversation, because resuming it drags back a pile of context that no longer describes the work in front of you.

Two sibling reports sit in the same class, and their titles are also verbatim:

A bug report: "Subagents persist in memory after stopping without manual removal". Stopped subagents keep occupying memory until they are removed by hand.
A bug report from another tracker: "memory_search hybrid ranking drops the only chunk that contains the whole query". A sentence quoted verbatim from an indexed note does not return that note.

None of these are model-quality problems. They are one problem wearing three hats: memory with no boundary and no plan. What gets kept, when it gets dropped and who decides are all left to whatever the host happens to do at the moment.

Ruling out the two reflexes

A better prompt does not fix it. A prompt is an input, not a store. It has no index, no source pointer and no address three sessions later. If the thing you needed was never written down somewhere addressable, no amount of instruction text brings it back.

A bigger context window does not fix it either. It moves the wall. Compaction still fires on its own schedule, and whatever was not durably stored at that moment is gone. Resuming a stale session is the visible edge of that: the context is technically still there, and it is precisely the part that no longer applies.

The common denominator is a missing layer between the transcript and the model: something that decides at write time what is worth keeping, keeps it verbatim, and drops the rest on a schedule instead of never.

Five write-time moves

These are the rules I ended up enforcing in HyperMarrow, a local-first memory layer for agents on Windows. They are ordered by how early they act, because every failure above is decided at write time, not at query time.

1. Decisions are written down, not re-derived. A preference, a decision or a conclusion has to land in durable local storage with a source and a timestamp. The stale-session request is a user asking, in effect, for the opposite: that the things already decided do not have to be re-established every time context is rebuilt.

2. Write before you compact. Nothing is allowed to summarise or drop the working context until that durable copy exists and has been acknowledged. Once the durable copy comes first, a summariser drops from single point of failure to convenience. The subagents-persist report is the same rule seen from the other side: memory that is never reclaimed is as bad as memory that is lost.

3. Forgetting is bounded and scheduled, and pinned records never decay. An unbounded memory is not a feature. Sessions that stopped being relevant should age out on a schedule instead of being carried forward forever, while records you explicitly pin are exempt. This is what "suggest a new conversation" asks for one level up: a deliberate boundary on what a session still carries.

4. Recall returns your words, not a summary of your words. If what got written was already lossy, no ranker recovers the sentence you actually needed. The hybrid-ranking report is a reminder that recall quality is capped by write quality, and ranking is the second-most important knob, not the first.

5. The privacy boundary is a setting, not a promise. Where records live, and whether a given record may leave the machine, is a configuration decision rather than a paragraph. Memory that holds decisions has to make that boundary explicit, because the alternative is a policy statement you cannot audit.

The modules are record, recall, consolidation and file-bridge, exposed over MCP, so the agent does not need a bespoke integration per tool.

Mapping the rules back to the reported symptoms

Resuming a large or stale session. Retrieval is scoped and ranked, so resuming does not mean re-injecting everything. Old records decay on schedule; pinned ones do not.
Subagents persisting after stopping. Reclamation is part of the write contract: a record with no live referent is collected, not left to accumulate.
Quoted sentences losing to paraphrases. Short queries against long records still fail, which is why the fix starts at write time with tighter, verbatim records rather than at the ranker.
"The agent forgot what we decided." The decision has an address, a source and a timestamp, so it can be re-found from a different session instead of being re-explained.

What is still wrong

The reports are fair criticism, so the limits are worth stating plainly:

Hybrid ranking is genuinely hard. A quoted sentence does not always outrank a paraphrase, and short queries against long records still fail more often than I would like.
Scheduled decay needs a usable notion of relevance. Get it wrong in the aggressive direction and you drop something that mattered; get it wrong in the patient direction and you are back to unbounded memory.
Anything that depends on a model to classify memory kinds will misclassify some fraction of the time. It fails more quietly than losing the data, but it still fails.

Over to you

If you run agents across long-lived sessions: what is the thing you keep having to re-establish, and what would you want forgotten instead?

HyperMarrow is a Windows desktop memory layer. The local-first build is here: HyperMarrow

Disclosure: I build HyperMarrow, so read the above with that in mind. The issue reports quoted here are real and public, and no numbers, user counts or testimonials have been invented for this post.

Session discovery: conversations become unreachable, plus ghost and duplicate project entries

qianqiuwanzi — Tue, 06 Oct 2026 03:30:11 +0000

The public issue trackers of the major agent CLIs are the best place to read what "my agent forgot" actually looks like in the wild. One of the most detailed reports is titled, verbatim:

Session discovery: conversations become unreachable, plus ghost and duplicate project entries

The reporter works with roughly ten active conversations. The complaint is not that the model got weaker. It is that the conversations stopped being addressable: some of them cannot be opened at all, and the project list has grown ghost entries plus duplicates of the same project, so there is no obvious place to go back to.

Two sibling reports describe the same class of failure from different angles:

A feature request asks the CLI to suggest starting a new conversation when resuming a large or stale session, because resuming it drags in context that no longer describes the work.
A second bug report asks for conversation-scoped visibility, so an agent serving one channel can recall sibling threads in that channel without reaching into the other channels it serves.

None of these are recall-quality problems in the narrow sense. They are storage and addressing problems, and they sit underneath everything else.

Ruling out the two reflexes

Rewriting the prompt does not fix it. A prompt is an input, not a store. It has no index, no source pointer and no address three sessions later. If the thing you need was never written down somewhere addressable, no amount of system-prompt engineering brings it back.

A larger context window does not fix it either. It moves the wall. Compaction still fires on its own schedule, and whatever was not durably stored at that moment is gone. This is not hypothetical: another report in the same tracker describes an idle session being compacted before the prompt cache expired, with no opt-out, and logged as if it had been a manual action.

The common denominator is a missing layer between the transcript and the model: something that writes facts down, gives each one an address, and can find it again from a different session.

Four write-time rules

These are the rules I ended up enforcing in HyperMarrow, a local-first memory layer for agents on Windows. They are ordered by how early they act, because the failures above are decided at write time, not at query time.

1. Write before you compact. A preference, a decision or a conclusion has to land in durable local storage with a source and a timestamp before anything is allowed to summarise or drop the working context. The idle-compaction report argues for this rule by counterexample. Once the durable copy exists first, a summariser drops from single point of failure to convenience.

2. Decide at write time what kind of memory it is. A stated preference has to survive verbatim; a conclusion is durable but rewritable; routine chatter is noise. Sorting after the fact is too late, because the original phrasing has already been discarded. In practice that means three buckets with three retention policies, not one undifferentiated pool of vectors.

3. Recall returns your words, not a summary of your words. If what got stored was already lossy, the best ranker available cannot recover the sentence you actually needed. This is why rule 2 matters more than retrieval tuning: recall quality is capped by write quality.

4. Forgetting is scheduled and bounded, and pinned records never decay. An unbounded memory is not a feature. Sessions that stopped being relevant should age out on a schedule instead of being carried forward forever, while records you explicitly pin are exempt. The stale-session request above is a user asking for exactly this, one level up.

Two constraints run across the whole set: memory is local by default, and the privacy boundary is a setting rather than a promise. Where records live, and whether a given record may leave the machine, is a configuration decision, not a policy paragraph.

Mapping the rules back to the reported symptoms

Conversations become unreachable. Each session gets a stable local record with an address that does not depend on scrollback or on the CLI's own session list. Recall queries the store directly.
Ghost and duplicate project entries. The project entry is derived from the stored record instead of being accumulated separa官网 hm.qianshi.cooly, so the list cannot drift away from what actually exists.
Resuming a large or stale session. Retrieval is scoped and ranked, so resuming does not mean re-injecting everything. Old records decay on a schedule; pinned ones do not.
Conversation-scoped visibility. Scope is a property of the record, so recall can be limited to one channel's threads without exposing the rest.

The modules are record, recall, consolidation and file-bridge, exposed over MCP, so the agent does not need a bespoke integration per tool.

What is still wrong

The reports above are fair criticism, so the limits are worth stating plainly:

Hybrid ranking is genuinely hard. Short queries against long records still fail more often than I would like, and a quoted sentence does not always outrank a paraphrase of it.
Session addressing is only as good as the session identifiers the host gives us. If the CLI renames or recycles them, the memory layer has to reconcile, and reconciliation can be wrong.
Anything that depends on a model to classify memory kinds will misclassify some fraction of the time. It fails more quietly than losing the data, but it still fails.

Over to you

If you run agents across several sessions: what is the thing you keep having to re-establish? And if you have filed one of these reports, I would rather hear where this model still does not match what you saw.

HyperMarrow is a Windows desktop memory layer. The local-first build is here: HyperMarrow

Disclosure: I build HyperMarrow, so read the above with that in mind. The issue reports quoted here are real and public, and no numbers, user counts or testimonials have been invented for this post.

Your AI forgets what you told it. A memory layer fixes most of it

qianqiuwanzi — Sat, 03 Oct 2026 01:53:51 +0000

You 官网 hm.qianshi.cooll your agent something on Monday. On Tuesday it asks you again. Not because it did not listen. The transcript is still there. The problem is that nothing which survived the session is addressable.

A recent post on Dev.to put a number on that feeling: your AI ignores what you told it most of the time. I do not have a better measurement and I am not going to invent one. What I can do is point at public issue trackers, where the same failure was filed by people who hit it in production.

One report: assistant text emitted before a tool call is dropped from the UI, even though the text is persisted in the transcript. Another: conversations become unreachable, plus ghost and duplicate project entries. A third is a request rather than a bug: when resuming a large and stale session, suggest starting a new conversation instead.

Read those three together and the shape is clear. The memory is often already written down. What is missing is a way back to it.

The fix people reach for first

Rewriting the prompt. "Remember that I prefer X." It works inside one session and evaporates with the context window, because a prompt is an input, not a store. You cannot index it, version it, or cite it three sessions later.

The second instinct is a bigger context window. That moves the wall, it does not remove it. Compaction still fires, and it fires on its own schedule rather than on yours.

Four things a memory layer has to do instead

I build HyperMarrow, a local-first memory layer for agents. All four of these are write-time decisions, not query-time tricks.

1. Write before you compact

Preferences, decisions and conclusions go to the local store first, each with a source and a timestamp. Only then is the working context allowed to be summarized or dropped. If the summarizer throws something away, the durable copy is already on disk.

2. Separate the kinds of memory at write time

Not every sentence deserves the same treatment. A stated preference, like "we use pnpm here", has to survive verbatim. A conclusion is durable. Raw chatter is noise. Sorting them at query time is too late, because by then the original phrasing is gone.

3. Recall returns your words, not a summary of your words

This is where the reported bugs bite hardest. If what got stored was already a lossy summary, no ranker can recover the sentence you needed. Keep the exact phrasing and recall can hand it back. That is the part which makes an agent stop re-asking.

4. The boundary is a setting, not a promise

On a local-first design the store lives on your machine, and sending context to a hosted service is an explicit action rather than the default. "You own your data" and "your data never leaves your machine" are different statements, and only the second one is checkable from your side.

What changes in practice

The agent stops starting from zero. It knows you said pnpm. It knows which approach you already ruled out. It can point at the paragraph where you said it. The difference is not that the model got smarter. The difference is that it can read something which outlived the session.

If you run agents

The useful question is not whether your agent has memory. It is where that memory lives, and whether it is still addressable tomorrow. If the answer is "somewhere in the context window", you are one compaction away from starting over.

I am building HyperMarrow, the local-first memory layer described above. Docs and the client are here: HyperMarrow.

If you run agents: what is the thing you have to repeat most often?

(Disclosure: I build HyperMarrow, the local-first memory layer described above.)

Four agent-memory bugs from real repos: idle compaction silently discards working context

qianqiuwanzi — Fri, 02 Oct 2026 02:00:55 +0000

Open a long-running agent session, walk away, come back. In at least one widely used coding agent, compaction can fire while the session is idle and drop context you still needed, with no way to opt out. The issue title says it better than I can: idle compaction silently discards working context in long-running sessions.

That report is not an outlier. Reading the public issue trackers of the major agent CLIs, the same handful of failures keeps showing up. They are not exotic edge cases. They are what happens when "memory" is really just a context window with a summarizer bolted on.

I work on HyperMarrow, a local-first memory layer for agents. I treat these reports as a backlog rather than as talking points. Here are four of them, quoted from the trackers, and the write-time rule each one implies.

Bug 1. "Idle compaction silently discards working context in long-running sessions; no opt-out"

Source: anthropics/claude-code issue 98747

What happens: compaction is a background job. It runs when the session is idle, not when it is safe. Anything the summarizer judges low-value at that moment is gone, and the user never got a vote. A mirror-image report in another repo describes subagent-completion turns skipping preflight compaction, so a session over its threshold never gets compacted at all.

The rule: a write decision has to happen before compaction, not after it.

In our design, compaction is not allowed to be the first thing that touches recent state. Records, decisions and conclusions are written to the local store first, each with a source tag and a timestamp. Only then may the working context be summarized or dropped. If the summarizer throws something away, the durable copy is already on disk. That turns compaction from a data-loss problem into a view problem.

Bug 2. "memory_search hybrid ranking drops the only chunk that contains the whole query"

Source: openclaw/openclaw issue 162764

What happens: retrieval quality is treated as a ranking problem. It is usually a writing problem. If what you stored was already a lossy summary, no ranker can recover the sentence you needed.

The rule: decide at write time what is a fact, what is a decision, and what is noise.

Our layer separates the three. Facts and decisions are stored verbatim and immutably. Noise is stored as a pointer, or not stored at all. Retrieval then has something exact to hit. When a recall misses, the first question is not "which embedding model", it is "what did we fail to write down".

Bug 3. "Subagents persist in memory after stopping without manual removal"

Source: anthropics/claude-code issue 98804

What happens: everything is remembered forever, so stale agents, dead sessions and one-off experiments accumulate and start to pollute later decisions.

The rule: forgetting has to be bounded and scheduled, not manual.

Our layer runs a decay pass. Low-value records fade along a curve, pinned records never fade, and nothing is hard-deleted while it is still referenced. The user should not have to be the garbage collector. A memory system that needs manual cleanup is not a memory system, it is a leak.

Bug 4. "Paragraph anchors with cross-session references"

Source: anthropics/claude-code issue 98768 (a feature request)

What happens: users want to point at one paragraph from an earlier session. Today they can point at a whole conversation, or at nothing.

The rule: continuity has to be addressable.

This one is filed as a feature, and that is the interesting part. The distance between "I remember your last chat" and "I can cite the exact paragraph from three sessions ago" is where continuity actually lives.

The rules, in one place

Write before you compact. The durable copy exists before the summarizer runs.
Separate facts, decisions and noise at write time, not at query time.
Forgetting is scheduled and bounded; pinned records never decay.
Continuity is addressable across sessions, down to a paragraph.
All of it stays local by default, and the privacy boundary is a first-class setting rather than an afterthought.

None of this is exotic. It is the boring part of storage that most agent stacks skip, because a context window is good enough in a demo and the bill arrives later.

If you run agents

The useful question is not whether your agent has memory. It is where that memory lives, and what happens to it when the session ends. If the answer is "in the context window", these four bugs are already on your roadmap, whether or not you filed them.

I am building HyperMarrow, the local-first memory layer described above. Docs and the client are here: HyperMarrow.

If you maintain an agent runtime: which of these four have you hit, and which one do you consider unfixable?

(Disclosure: I build HyperMarrow, the local-first memory layer described above.)

The 3 Quiet Tricks That Make AI Memory Actually Pay Off Over a Year

qianqiuwanzi — Thu, 01 Oct 2026 01:45:02 +0000

Everyone demos AI memory with a fresh session. The real test is what happens after a year of use.

A memory layer that only stores is a junk drawer. The systems that pay off long-term do three quiet things:

Consolidate — turn raw session logs into durable facts, so the useful signal survives.
Forget on a schedule — let low-value noise decay instead of piling up.
Stay local — the longer the history, the more sensitive it gets; keeping it on your disk keeps the risk bounded.

We built HyperMarrow around exactly these three. The four building blocks (recall / intercept-record / consolidation / file-bridge) are what make a year of memory feel like an asset instead of a liability.

The download and docs are here: https://hm.qianshi.cool/api/v2/dl?from=devto.

What would change for you if your AI's memory actually compounded instead of rotting?

(Disclosure: I build HyperMarrow, the local-first memory system described above.)