[Feature] Built-in persistent long-term memory for agents

[goodayforyou]

Currently the agent only has in-session context (window + goal/todo tools); there is no cross-session persistent memory. After a session ends or restarts, context is lost. Projects work around this by keeping external memory in docs/git.

Request:

• A persistent, structured memory backend (file or database) that the agent can read/write across sessions.
• A simple, unified interface for the agent to store and retrieve long-term memory (e.g. key-value / searchable records), independent of the conversation window.

This would let an agent resume / continue work in a new session without re-reading everything from scratch.

Use case

Operator keeps preferences and project state in long-term memory so a new agent run can pick up where the last one left off.

[freelancing-solutions]

sorry dude i had to steal this idea, implementing it now on my own local agents.

[Spirtxiaoqi7]

We have been working on this exact problem as two independent DeepSeek Harness community plugins. They provide a local implementation today without modifying the DSH chat/provider core.

Structured Session Memory

mindspace-dsh-session-memory stores persistent, session-isolated agent memory under the current DSH Home and exposes explicit model read/write tools plus a user management UI.

Instead of an unbounded transcript dump, it maintains governed sections for:

• confirmed and inferred user profile with evidence references;
• categorized preferences and assistant instructions;
• relationship or working-role mission and role-play presets;
• append, merge, replace and skip activity auditing.

The model can merge new facts and replace conflicting information, while the user can inspect and edit what was stored. This handles the small, high-priority layer of long-term memory: identity, preferences, project operating rules and agent state that should survive restarts.

Local RAG for scalable history and project knowledge

mindspace-dsh-local-rag provides the larger searchable layer through two governed stores:

• global user-uploaded knowledge such as PDF, DOCX, TSV/CSV, TXT, Markdown, JSON and HTML;
• DSH native compaction/end summaries isolated by the current session.

It deliberately does not index every raw chat turn. Only committed DSH compression summaries are deduplicated and persisted. Models receive the standard search_local_memory tool and decide when older context is actually needed, rather than having retrieval injected into every prompt.

Retrieval stays local: BM25+ works without a vector model, while an explicitly started local embedding model adds vector retrieval and RRF fusion. Documents and summaries are visible, editable, logically deletable and versioned for rollback; results retain timestamps, turn/sequence ranges and source locations.

Together they cover both parts of this proposal:

• structured continuity for preferences, identity and agent operating state;
• searchable continuity for older session summaries and project documents.

The two packages are independent and can be installed or removed separately. Both keep user data under DSH Home. The Local RAG architecture and combined deployment notes are documented in Discussion #1109.

These are community plugins rather than an official built-in DSH backend, but they can serve as a concrete reference for an upstream memory interface: stable session identity, explicit model tools, post-commit persistence hooks, provenance, user-visible governance and non-destructive versioning.

[GIT121995]

The gap is real, and a few community plugins already fill it locally. One more route, focused on bounded + auditable: dsh-memory-gate (npm: dsh-memory-gate, MIT). It stores stable facts as revocable claims (SQLite + FTS5, no embedding calls) and runs CBDC (Claim → Belief → Decision → Consumption) authority gating before every model call — retrieved ≠ injected. Each recall lands as an explainable use / verify / ignore decision with a full audit trail, default budget of ≤3 claims / 1200 chars, and no second model call.

dsh plugin --profile web add dsh-memory-gate

/memory commands cover remember/list/search/explain/feedback/forget with session/workspace/global scopes. For comparison, dsh-memory-evolve (5-track memory + self-evolution) and dsh-mneme (SQLite + human-editable Markdown mirror) are the other popular routes — roughly "trust the agent's own notes" vs "gate what gets injected".

[jimy-r]

Whatever backend lands, what kept ours useful over months of daily use was write discipline more than storage. Three rules did most of the work.

Memory points at the source of truth instead of copying it. A note recording where project state lives cannot contradict the file it points at. A copy eventually always does, and a memory that contradicts its source is worse than no memory.

Every write is one of add, update, delete, or no-op against the existing store, never a blind append. Append-only memory grows until the useful facts drown in near-duplicates.

The agent verifies before asserting. A memory entry is a point-in-time claim, so it gets checked against current state before being acted on, and pruned when wrong.

Structurally, a small index loads at session start and typed topic files load on demand, with a size ceiling on the index. That keeps per-session cost flat as the store grows. Documented here: Memory points, it doesn't mirror

[GIT121995]

These write rules match our experience closely — especially "write a supersede, never blind-append" and "verify before asserting". We built the second one into dsh-memory-gate as CBDC (Claim → Belief → Decision → Consumption): every memory passes a use/verify/ignore decision before it can enter context, and verify is exactly your "check against current state before acting". The first one (supersede over append) is the gap we haven't closed yet — our schema already has a superseded state that's currently unused, so your PATTERNS doc is a useful spec for it. The bounded-index point is the most valuable one for us: flat per-session cost as the store grows is the next thing we're tackling.

[jimy-r]

The mechanics that hold ours flat, since that's your next problem. The index file carries a hard ceiling (ours is 200 lines / 25 KB) and an explicit migration rule. Approaching the ceiling, older entries move out to per-topic files and one-off events leave the index entirely. Per-session cost is then the index plus whatever topic files the session actually opens, so it stays flat as the store grows.

The habit that did more for recall quality than any storage change was writing each index line as a retrieval trigger rather than a summary. The line describes when the topic file is relevant, not what it concludes. The index is the only thing loaded at session start, so that one-line description is what decides whether the right file gets opened at the right moment.

And the superseded state going unused matches our experience. Ours only started being exercised once consolidation ran on a cadence with a concrete dedup rule. Above roughly 60% overlap with an existing entry, the write becomes an update to that entry instead of a new one. Without the cadence and the threshold, supersede stays a schema feature nobody triggers.

[weijiafu14]

这里再补一条“直接复用现成生态”的路线：Pi 的 pi-hermes-memory 可以通过 pi2dsh 原包运行在 DSH，不需要重写成 DSH 专用插件。

dsh plugin --profile web add pi2dsh@0.11.0
dsh plugin --profile web add pi-hermes-memory

它覆盖了原帖要求的两部分：

• 持久化写入/修改/删除与检索：memory_add、memory_replace、memory_remove、memory_search；
• 跨会话连续性：全局 + project 两级 Markdown memory，SQLite FTS5 扩展存储与 session_search；
• 每 10 轮/15 次工具调用自动回顾，提取 failure、correction、insight、preference、convention、tool-quirk；
• 写入前做 secret / prompt-injection 扫描，API key、token、SSH key 不会被当记忆保存；
• 默认只注入轻量 memory policy，需要时再调用搜索，不会把整库塞进每轮上下文。

这条链路已经做过真正的跨进程验证：会话/进程 A 写入一条 memory，完全新进程 B 能通过 memory_search 读回；在 DSH runtime 中 memory_add → memory_replace → memory_search 也都执行成功，不是只看到工具名。验证结果在 community black-box results。

[GIT121995]

This is exactly the spec we needed — the 60%-overlap update-instead-of-append rule and the cadenced consolidation turn superseded from a dormant field into something that actually fires. We're going to adopt that for our next iteration. The index-ceiling + per-topic-file split is also a cleaner answer to flat cost than the injection-budget window we were planning; the two are complementary (flat retrieval + flat injection). And good to have the "trigger, not summary" principle confirmed — that's what our trigger-term index already does.

[Electricitysheep]

内置长期记忆的诉求一直有（#1345/#1822 记忆体/#1448 等都是），官方如果做内置记忆 seam，社区那些记忆插件（dsh-sgme/AgentSoul/dsh-memory）就能挂上来。

我们第 15 章生态报告把"记忆/人格 seam"列为官方能力缝之一，这帖正好佐证：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/15-ecosystem-report.md

[sdhjad]

新建了一个dsh的群，里面大家都在交流dsh的落地应用的大神，欢迎大家一起交流。

[sdhjad]

[etzhe]

This is the retrieval/transcript side of the cross-session knowledge problem, complementary to this "persistent memory" (write/discipline) discussion: a first-class way to search the actual past conversation text (WB-style conversation_search), so the agent/human can recover prior discussions without relying on curated summaries. Drafted as a separate Ideas thread → #4752.

--- 这是"跨会话知识"的检索/原文一侧，与"长期记忆/持久存储"（写入与纪律）互补：让 agent/人直接搜到过去真实聊过的话，而非依赖已提炼的摘要。已另开 Ideas 帖 → #4752。

[hackernotfound]

A slice of this exists as a plugin today, for one specific kind of memory: what you keep telling the agent. (Disclosure: I maintain it.)

Tacit watches the turns that go badly plus your own corrective messages, distills them into short directives
e.g. "The user often omits which app they mean , check apps/web first"
and injects them as a visible, editable system-prompt section in every new conversation. It carries across sessions, scopes per workspace, and every directive has a receipt of where it came from and what it cost.

It deliberately does not try to be general task memory: no facts/episodes store, no read/write interface for the agent. So a built-in structured backend like this proposal would still be needed for that layer ,Tacit would happily sit on top of it for the preference layer.
Hopefully you find it useful

[etzhe]

@hackernotfound Thanks for the disclosure and for drawing the boundary so precisely. Tacit covering the preference/correction layer — as visible, editable directives with a source/cost receipt — is a great fit for that slice, and your explicit "no general task memory behind it" is exactly why a structured built-in seam is still needed for the rest. Agree they're complementary rather than competing: a native auto-load of the user's markdown-memory / injection layer (the #5333 ask) could let something like Tacit sit on top for the preference layer. I'll keep #5333 scoped to the markdown-memory + injection seam so it doesn't overlap with Tacit.