Introduction

DeepSeek Harness (DSH) adopts a plugin-based architecture, aiming to open core capabilities to the community. When building agentic workflows, cross-session memory retention is an essential requirement. Traditional solutions usually rely on external vector databases or memory services, which introduce latency and privacy risks. The following section introduces dsh-memory-layer, a “memory layer” plugin for DSH. It uses local single-file storage and trigger-based rules to address memory persistence and recall.

What It Is

This is a purely local memory plugin whose core is a single-file SQLite database. It does not perform vector retrieval, build knowledge graphs, synchronize to the cloud, or provide a Web UI. Its responsibility is singular: maintain a local memory store within the DSH process and retrieve the memories that should be surfaced when a specific signal is triggered.

Core Features

The plugin uses a four-layer design to ensure memory reliability and controllability.

Storage Layer: Local SQLite

Data is stored in the local file system at .dsh/biomemory/biomemory.db (WAL mode). Main fields include realm (isolation dimension, user or project), mtype (type, workflow/error/decision/fact), trigger (trigger signal string), and text (body content). All delete operations use a “tombstone” mechanism: they modify only the status flag and do not physically delete data.

Recall Layer: Trigger-Driven

The plugin does not rely on the model for automatic recall; instead, it performs deterministic recall based on the current session context. Trigger signals come from the current working directory and the 12 most recent tool calls, expressed as readable strings:
* file:<filename>
* tool:<tool name>
* err:<error code>

After a match, memories are injected by priority (workflow > error > decision > fact), with a budget limit per injection (up to 8 entries, 1200 characters).

Cleanup Layer: Five Interpretable Rules

Cleanup is performed using the /memory compact command, and each eviction is written to compact.log:
1. Same-key overwrite: A new memory overwrites an old memory (the old entry is tombstoned).
2. Fact expiration: Unused for 30 days (≤ 1 use) → tombstone.
3. Workflow/Error/Decision de-weighting: Unused for 90 days → weight halved.
4. Error and Decision entries are never automatically deleted.
5. Each eviction record includes the timestamp, fingerprint, and rule summary.

Adaptation Layer: Workflow Chains

When the same trigger string occurs more than 3 times, related memories are automatically upgraded to the workflow type and assembled into a chain in chronological order. For example, it records the sequence “open file -> run tests -> modify code”.

Installation and Enabling

Before installing, make sure Node.js >= 22.19.0 is installed. Use the official command to install:

# Replace --profile web with your actual profile name
dsh plugin --profile web add github:KLRSL/dsh-memory-layer

After installation, DeepSeek Harness automatically hot-mounts the plugin.

Typical Usage

The plugin provides the /memory command and the memory_recall tool.

Command-Line Interaction

/memory list | query <term> | add <content> | edit <fp> <new_content> | remove <fp> | undo <fp>
/memory pin <fp> | unpin <fp> | entries [term]
/memory compact [--dry-run] | dump

Tool Invocation

Call the memory_recall tool in code or prompts to perform explicit recall.

Write Approval

For important memories (such as user preferences, decisions, or corrections), the plugin supports DSH’s official approval mechanism. If the approval service is unavailable, writes are rejected by default (fail-closed; this can be relaxed by configuration).

Use Cases and Caveats

This plugin suits developers who need memory capabilities with high privacy, low latency, and interpretability. It is suited for single-machine environments, not for scenarios requiring multi-machine collaboration.

Caveats:
1. No vector retrieval: Identical inputs must produce identical trigger signals; the retrieval path is deterministic.
2. No automatic reflection: It does not rely on model-based induction; workflow chains are based entirely on repeated trigger records.
3. Zero service dependencies: Data is fully local, with no network requests and no telemetry.

Short Conclusion

After the steps above, you have mounted a purely local memory layer on DeepSeek Harness. It does not provide flashy platform features; it only provides reliable storage and trigger-based recall. The data remains on your own machine, and migration is as simple as copying the file. For more details, see the GitHub repository.