dsh-mnemon: composable three-tier memory for DeepSeek Harness

The problem dsh-mnemon solves inside DeepSeek Harness

An agent session that spans days needs three different kinds of remembering, and most memory plugins collapse them into one store. dsh-mnemon separates them. Runtime memory holds preferences, working agreements and facts needed on the next turn, and reaches the model as a compact USER or MEMORY projection. Documents hold designs, investigations, procedures and handoffs, and reach the model through search followed by reading the relevant narrative. Memory Spaces hold durable facts, decisions, entities and relationships, and reach the model as on-demand evidence from enabled backends.

The package describes itself in package.json as a "Composable three-tier memory control plane for DeepSeek Harness". The audience is therefore narrow and specific: people running a DSH Host who want persistent context, project documents and long-term evidence in one plugin, and contributors who want to swap out the parts. The README states that the default Starter installs a tested plugin combination and that contributors can replace or extend its parts without rebuilding the memory system. If you are not on DSH, nothing here applies to you.

Source plus Strategy compiles one View per turn

The composition model has three named parts. A Source owns memory, its projection, read and write operations, and optional DSH pages. A Strategy chooses how available Sources participate: selection, resident context, retrieval and guidance. The README is explicit that pure composition does not write memory, which is a useful boundary because it means a Strategy cannot silently mutate a Source's data.

Core sits between them. It validates the proposal, asks Sources for bounded projections and compiles an immutable View. The DSH Host pins that View to the executing turn and controls tool access. According to the README, a View includes context and the scoped routes and actions the LLM can use next. It is not another database and not a frontend page. Memory Spaces owns its Provider child Fibers, and Core exposes only a small ctx.mnemonMemory contribution service. The repository layout matches this description: src/ for the core, plugins/ for the shipped plugins, provider-lab/ for provider experiments, and tests/ alongside them.

The practical consequence is that the same public contracts serve the default plugins and external repositories. A Source author keeps their data and backend choices; a Strategy author reuses those capabilities plus the turn lifecycle, budgets and test fixtures.

Installing dsh-mnemon and adding your first memory

You need a compatible DSH Host, and the README states that Mnemon Native also needs a separately installed mnemon CLI. Installing the npm Starter does not install that binary or any third-party backend services. Node 20 or later is required by the engines field in package.json.

Check the CLI first, then add the plugin to a profile and start the web interface:

mnemon --version
dsh plugin --profile web add dsh-mnemon
dsh web

For a headless setup, the README gives a separate command that adds the same package to the headless profile:

dsh plugin --profile headless add dsh-mnemon

After the plugin loads, the README's first-use path is: open Memory System then Status, and add a Runtime memory. Select a DSH workspace before creating Documents, even when storage is global. To keep long-term facts, create a Memory Space with an explicitly selected Provider. Sidebar is the default placement; an optional Builtin placement uses the same pages. The current development baseline is DSH 0.1.5-rc.1 on npm latest, and the README points to a platform installation guide and verified compatibility baselines rather than listing them inline.

Idle review, spawn checkpoints and the 20-attempt limit

Automatic idle review is the part most likely to surprise an operator. The README states that it now uses bounded spawn checkpoints, a five-minute minimum interval and a 20-attempt limit per loaded session, and that it can be disabled independently. Those three numbers are the whole cost-control story: without them, an idle session could keep spawning review work indefinitely.

Two failure behaviours are documented. Published Agent Teams tool conflicts pause review before any child starts. Failed runs retain committed receipt metadata and are never replayed automatically. That second rule matters because it means a failed review is not retried behind your back; you decide what happens next.

The README also distinguishes which paths spend model calls. Direct retrieval does not spawn a Mnemon task Agent, while Agent Query, semantic writes and maintenance may use the configured model. The workflows and costs reference page is where that split is documented in full. If you care about token spend, that page is the one to read before enabling anything beyond the default Starter.

Where dsh-mnemon is the wrong tool

The hard dependency chain is the first limitation. The README says Mnemon Native needs a separately installed mnemon CLI, and that installing the npm Starter does not install that binary or third-party backend services. So a clean npm install does not give you a working long-term memory backend. You either install the CLI yourself or choose a Provider that does not need it.

Second, the plugin is bound to DSH. Every tier reaches the model through a View that the DSH Host pins to the executing turn. There is no documented way to use the three tiers from a different agent runtime, and the package is published as a DSH plugin rather than a standalone library.

Third, upgrades are not always drop-in. The README states that existing Sessions with source summary requires notice form need an explicit copy repair using dsh-mnemon-repair-session --input FILE --output NEW_FILE, and points to legacy Session recovery before replacing any artifact. That is a real migration step, not a footnote. If your sessions predate the current format, budget time for the repair path rather than overwriting files in place.

How this differs from a single-store memory provider

The package keywords list a set of adjacent systems: mem0, honcho, hindsight, retaindb, byterover, supermemory, openviking. The repository does not describe how any of them work, so the useful comparison is structural rather than feature by feature. A typical single-store memory provider gives you one place to put facts and one retrieval path back out. dsh-mnemon splits that into three tiers with different delivery mechanisms: a compact projection for runtime, search-then-read for documents, and on-demand evidence from a backend for Memory Spaces.

The second difference is the extension contract. Sources and Strategies are separate roles with separate responsibilities, and the README states that the same public contracts serve the default plugins and external repositories. A single-store provider usually exposes a client library and a fixed retrieval policy. Here, retrieval policy is a Strategy you can replace while keeping the Source's data and backend choices intact. That is more moving parts to understand, and it is the reason the architecture documentation exists as a separate page.

Licence, maintenance and upgrade cost

The licence is MIT, per both the LICENSE file and the package.json license field. MIT permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. THIRD_PARTY_NOTICES.md exists in the repository root, which suggests bundled dependencies carry their own notices; check that file before redistributing a built artifact. This is a description of the licence terms, not legal advice.

The repository is not archived. The last push was on 2026-09-16, and v0.5.10 was released the same day, with v0.5.9 on 2026-09-14 and v0.5.8 on 2026-09-11. Three releases in six days is a fast cadence, and the patch numbers suggest incremental fixes rather than a stable line.

Upgrade cost has two documented components. The v0.4 to current path retains the familiar configuration, data and workflow, and exposes three optional enhancements in Settings then Memory System; the README notes that no View tab or generic memory-plugin manager is added. The DSH 0.1.5 compatibility path is the more expensive one, because of the session repair command and the warning to check recovery documentation before replacing any artifact. The README does not document rollback.

Editorial conclusion

Adopt dsh-mnemon if you already run a compatible DSH Host and want runtime preferences, searchable project documents and provider-backed long-term evidence kept as three distinct tiers rather than one undifferentiated store. Skip it if you are not on DSH, cannot install the separate mnemon CLI for Mnemon Native, or need a memory layer that works without a host. Before installing, check your DSH version against the documented 0.1.5-rc.1 baseline, confirm whether any existing Sessions carry the source summary requires notice form marker, and decide which Provider each Memory Space will use, because that choice determines whether the npm Starter alone is enough.

Frequently asked questions

Official sources

1. License: MIT
2. omdsh-dev/dsh-mnemon on GitHub
3. Project website
4. README
5. Releases