DEV Community: qianqiuwanzi

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

Local vs Cloud AI Memory: What You Actually Trade When You Pick One

qianqiuwanzi — Wed, 30 Sep 2026 02:27:42 +0000

Most teams pick an AI memory product by the model it uses. The more important question is where the memory physically lives.

A cloud memory layer is convenient — until you realize every decision, customer note, and internal context your team produces is now sitting in someone else's database. You traded ownership for convenience.

A local-first layer keeps the store on your own hardware:

Raw data never leaves the intranet unless you explicitly choose to share it.
Consolidation and forgetting run on machines you control.
Sharing is opt-in, per document, per person.

You still get retrieval-augmented memory. You just stop handing the crown jewels to a vendor by default.

I am building HyperMarrow, a local-first memory system for AI agents and coding assistants. The docs and download are here: https://hm.qianshi.cool/api/v2/dl?from=devto.

If you had to pick, where would your team's memory store physically live?

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

Looking for Tech Co-builders: Let's Make Local AI Memory an Open Standard

qianqiuwanzi — Tue, 29 Sep 2026 09:26:10 +0000

Local, private AI memory is where this whole space is headed — but the interfaces are still a mess. Everyone builds their own silo, and switching costs lock users in.

I have been building HyperMarrow, a local-first memory system with four building blocks (recall / intercept-record / consolidation / file-bridge), exposed over MCP so the data stays on the user's machine.

I am looking for a few technical co-builders who care about this problem: people who want to help shape how local memory is structured, shared, and made interoperable — not just ship another closed product.

What is on the table: architecture decisions, the open spec, and the hard parts (privacy boundaries, forgetting curves, cross-agent sharing). If that sounds like your kind of problem, the docs and contact path are here: https://hm.qianshi.cool/api/v2/dl?from=devto

What would make a local-memory standard actually stick for you?

(Disclosure: I build HyperMarrow, the local-first memory system described above — that is also why I am recruiting co-builders.)

What Your AI Should Remember — and What It Must Forget: A Privacy Boundary

qianqiuwanzi — Mon, 28 Sep 2026 06:20:54 +0000

Giving an AI a memory sounds great until you ask: what exactly is it keeping? A memory system with no boundary is just a surveillance machine you trained yourself.

The boundary we draw is simple and local:

Record the work, not the person. Decisions, code, fixes — yes. Private credentials, health, unrelated personal context — never.
The store lives on your disk. Nothing leaves unless you explicitly share it.
You can delete any record, and the deletion is real (local file, not a vendor's 'we deleted it' promise).

The test: if you would be uncomfortable reading it back aloud in a meeting, it should not be in the store.

I am building HyperMarrow around exactly this boundary. The docs are in my profile (?from=devto).

Where would you draw the line on what your AI is allowed to remember?

Wiring Local Memory Into Your Stack via MCP: A Practical Walkthrough

qianqiuwanzi — Sun, 27 Sep 2026 04:38:19 +0000

Most 'AI memory' demos hardcode the store. That breaks the moment you change models or add a second agent. The fix is to treat memory as a capability your tools expose, not a database you wire by hand.

Enter MCP. A local memory layer can expose recall / record / consolidation as MCP resources and tools. Any MCP-aware client — Claude, Codex, your own agent — can then read and write memory through one standard interface, with the actual data staying on your disk.

What that buys you:

Swap models without rewriting memory code.
One agent's record is visible to the next.
The store stays local; only the interface is shared.

I am building HyperMarrow, whose four building blocks are exposed this way. The docs are in my profile (?from=devto).

If you have wired MCP before, what was the hardest part to get right?

Build a Team Knowledge Base That Never Quits: Local Memory for AI Agents

qianqiuwanzi — Sat, 26 Sep 2026 01:45:27 +0000

The most expensive loss in a team is not a missed deadline. It is the knowledge that walks out the door when someone leaves — the 'why we built it this way', the fix nobody wrote down, the tribal context.

A local memory layer changes that. Every decision, fix, and discussion your agents and people produce gets consolidated into a shared, structured store that stays on your machines. New teammates — human or agent — start with the team's history already loaded.

It is not a wiki nobody updates. It is memory that writes itself as work happens, and forgets on a schedule so the noise fades.

I am building HyperMarrow, a local-first memory system for exactly this. The download and docs are in my profile (?from=devto).

What would you preserve if your team's memory could outlast any single person?

Why Enterprise AI Memory Should Never Leave the Intranet

qianqiuwanzi — Sat, 26 Sep 2026 01:11:02 +0000

When a company adopts AI memory, the first question should not be which model. It should be where does the memory live.

For an enterprise, memory is the most sensitive asset there is — it is a concentrated record of decisions, customers, and internal context. Shipping that to a third-party cloud by default is a liability most teams sign up for without thinking.

A local-first memory architecture keeps the store inside the intranet:

Raw data is never uploaded unless explicitly chosen.
Consolidation and forgetting run on local hardware.
Sharing is opt-in, per document, per person.

You still get the power of retrieval-augmented memory. You just do not hand the crown jewels to a vendor.

I am building HyperMarrow, a local-first memory system designed for exactly this boundary. The download and docs are in my profile (?from=devto).

For teams evaluating AI memory: what is your policy on where the memory store physically lives?

Turn Your Local Files Into Your AI's Second Brain (Without the Cloud)

qianqiuwanzi — Fri, 25 Sep 2026 16:16:46 +0000

Your best knowledge is not in chat history. It is in the folders on your disk — docs, notes, specs, past reports. The problem is your AI cannot see any of it without you pasting it in by hand.

A file-bridge fixes that. It maps your local files into the same memory layer your agent already uses, so a document becomes a retrievable memory — without uploading a single byte to a cloud.

How it works in practice:

You point the bridge at a folder.
Files are indexed locally (never sent out).
When you ask a question, the agent pulls the relevant passage the same way it pulls a stored memory.

The key word is local. The index lives on your machine. Your private docs stay private.

I am building HyperMarrow, whose file-bridge is one of four building blocks (recall / intercept-record / consolidation / file-bridge). The download and docs are in my profile (?from=devto).

Which folder on your machine would you most want your AI to actually understand?