DeepSeek Harness Memory Plugins: Eight Options, Zero That Deliver Team-Grade Memory

DeepSeek Harness Memory Plugin Summary

A practical guide to selecting and implementing DSH Memory plugins This article is based on DSH official documentation, the plugin directory, publicly available READMEs from plugin maintainers, and verified official integration instructions. Community plugins iterate quickly; capability descriptions here follow public materials. Before a formal install, pin DSH, Node/Python, plugin package, and backend service versions and complete a minimal runnable test.

Introduction: Memory issues ultimately lead to two layers

A coding agent that starts every new session from zero makes a poor working partner: it doesn't know project conventions, previously verified troubleshooting paths, or the preferences you have repeatedly corrected.

Memory plugins solve a complete chain: extract worth-keeping information from conversations and task results, recall relevant content for the current task, inject that content into the current context, and allow correction, down-weighting, expiration, and rollback when a memory is wrong.

But "being able to remember" is only the first step. One person's coding preferences can serve that person directly; a team rule affects every member, project, and agent. So memory deployment naturally splits into two questions:

Plugin research: Which DSH Memory plugins exist? How do they capture, retrieve, and store memories?
Layered design: How do you turn personal memories into trusted team memories? Which plugins fit the personal, project, and team layers?

The article has two chapters: Chapter 1 covers what the plugins are, how they work, and who they fit; Chapter 2 covers how to combine components to automatically distill individual experience into team memory, walking through a build troubleshooting case covering extraction, verification, promotion, recall, and invalidation.

Chapter 1: DSH Memory Plugin Research

1. Where does Memory sit in the DSH architecture?

DSH is a plugin-first agent harness; models, tools, sessions, context, and memory are all extended through plugins. Memory is not a separate "chat log file" but a processing chain spanning the agent lifecycle:

Lifecycle location	What Memory does	What to verify
`agent/pre-step`	Recall relevant memories before the current model step	Whether recall is automatic, whether there are timeouts and token limits
`system-prompt` or dynamic prompt section	Inject facts, indexes, usage guidance, or user profiles	Whether it injects memory content or merely tells the agent how to retrieve
`session/event`, `turn/end`	Capture user, assistant, and tool events; trigger summarization or writes	Whether raw conversation is saved and background writes are reliable
Native memory tool / skill	Let the agent search, read, update, and delete on demand	Whether the agent calls it reliably and whether writes need confirmation

Therefore, judging a plugin isn't just about asking "does it have Memory." Look at four verifiable behaviors:

When it writes: every turn, after task completion, or only on explicit memory?
When it recalls: automatic every round, or only when the model actively invokes a tool?
Where it writes: local files, SQLite, a vector store, a server-side space, or a cloud API?
What happens when wrong: are there source, status, conflict, expiration, deletion, and rollback mechanisms?

2. Plugins classified by three working modes

Type	Representative options	Core traits	Main trade-offs
Auto-recall	MemOS, OpenViking, Hindsight	Lifecycle hooks actively search and inject	Smooth experience, but needs stronger noise and permission governance
On-demand retrieval	memsearch, ReMe	Provide a retrieval tool or usage guidance; the agent decides when to check	More restrained injection, but depends on tool call reliability
Local auditable	dsh-auto-memory	Memory saved as readable files with candidate and confirmed states	Easy to migrate and delete, but personal governance doesn't equal team governance

"Auto-recall" isn't necessarily better: it reduces the agent's decision cost for proactive retrieval, but raises the governance bar for irrelevant and wrong memories entering context. "On-demand retrieval" is more restrained, but you must verify the model actually calls the tool at key moments.

3. Candidate plugins one by one

Each plugin follows the format positioning → core mechanism → strengths → limitations → ideal scenarios → recommendation. A quick table sets the impression; read details as needed. Descriptions are summaries of maintainer materials, not a performance ranking.

Plugin	One-line impression	Typical workflow	Why pick it
MemOS Local	Put a personal memory engine into the DSH local process	Turn capture → local memory → pre-step auto-recall	Run personal memory quickly without changing agent behavior
MemOS Cloud	Host memory search and writes with a managed service	Pre-turn search → context injection → post-completion add	Reduce the work of building a memory backend
OpenViking	A context database organizing memory, knowledge, and Skills	Session capture → context space → retrieval and tool access	Manage all context types an agent needs in one place
Hindsight	Project memory that continuously records repo decisions and engineering experience	Ingest history → project memory → bring context at work start	Reduce repeated explanation of project history and conventions
memsearch	Readable Markdown memory with hybrid search	Summaries to files → build index → agent on-demand retrieval	Auditable files plus extensible search
ReMe	On-demand search combined with background organization	Auto memory/organization → search tool → read per task	Control context noise while continuously organizing experience
dsh-auto-memory	Manage personal memory with files and statuses	Candidate write → confirm status → index and tool read	Local control, visibility, and correction
Mnemosyne	A general local memory backend candidate	Backend capability → DSH adapter TBD → lifecycle pending	Observe integration direction; not installed yet

When reading, distinguish three things: what the plugin project itself offers, what the DSH adapter actually connects, and what team governance still needs to be added. A server-side capability doesn't mean the DSH plugin has automatically wired it up.

3.1 MemOS Local DSH Plugin

Official references: MemOS Local DSH integration docs · MemOS repository

Positioning: provides auto-recall, turn capture, explicit memory tools, and a local Viewer inside the DSH process. Good for validating personal long-term memory first.

Core mechanism: the public integration doc describes bounded auto-recall and a background capture queue after turn end, and says the adapter runs MemoryCore and the Viewer inside the DSH Node.js process. It does not launch a MemOS JSON-RPC bridge or sidecar daemon.

Strengths:

Runs locally, easy to control the data path.
Auto-recall lowers the agent's proactive retrieval cost.
Explicit tools and Viewer make memory inspectable.
Good as a starting point for a personal-layer MVP.

Limitations: the local adapter isn't equivalent to a MemOS server deployment, and local storage shouldn't be conflated with server-side Cube capabilities. Isolation of personal, project, and team spaces needs redesign for your actual configuration.

Ideal scenarios: personal long-term memory, local-first, teams that want to validate cross-session value first.

Recommendation: evaluate it first for the personal layer; for team-layer work, add an independent candidate pool, promoter, and team read-only library on top.

3.2 MemOS Cloud DSH Plugin

Official references: MemOS Cloud DSH plugin docs · MemOS repository

Positioning: connects DSH's turn lifecycle to MemOS Cloud, emphasizing automatic search and automatic add.

Core mechanism: the public README describes calling /search/memory before the first model step of each user turn, and /add/message after the turn ends with completed status; supports filters like user, public, knowledge-base, metadata, and tags. Whether tool calls and results enter memory is controlled by includeToolMemory.

Strengths: the integration path is clear, the model doesn't have to decide to call a memory tool, and filters provide a base for user, project, or knowledge-space isolation.

Limitations: data goes to a cloud service; you must review sent fields, storage region, retention, deletion mechanisms, tenant isolation, error handling, and key management before using it. If internal conversation cannot leave the local or intranet, this cloud plugin stays in the evaluation stage.

Ideal scenarios: teams allowed to use external managed services and wanting to quickly validate automated Memory.

Recommendation: good for experience validation; not recommended for carrying internal code or business conversations without a compliance review.

3.3 OpenViking DSH Memory Plugin

Official references: OpenViking DSH Memory plugin · OpenViking multi-tenancy and ACL docs · OpenViking repository

Positioning: puts Agent Memory, knowledge retrieval, and Skills into a unified context database, not just chat summaries.

Core mechanism: public docs show the plugin recalls at agent/pre-step, captures sessions at session/event, commits when a threshold or end condition is met, and provides viking:// URI protection and the OpenViking MCP tool surface. Recall targets use the caller's own context spaces, e.g., viking://~/memories and viking://~/skills.

Strengths:

Memory, RAG, and Skills fit into one context system.
Server-side spaces, URIs, and ACL direction support platform building.
Better for long-running agent workflows.

Limitations: requires a reachable OpenViking service; personal and shared spaces don't equal completed team promotion. Cross-user clustering, de-identification, evidence thresholds, conflict handling, and team permissions still need separate design.

Ideal scenarios: teams with server-side deployment capability that want to unify Memory, knowledge, and Skills.

Recommendation: suitable as a project or platform-layer backend, but not as a complete "personal memory automatically becomes team rule" solution.

3.4 Hindsight Coding Agents

Official references: Hindsight Coding Agents · Hindsight repository

Positioning: project memory, reflection, and context injection for coding agents, focused on repository history, project decisions, and engineering conventions.

Core mechanism: the public integration doc describes background ingestion of repository history and conversations, bringing project decisions, conventions, and knowledge pages back into context when the agent starts work, with cloud, self-hosted, and local daemon deployment options.

Strengths: project-experience oriented, reduces the cost of repeatedly explaining the same project issue; also suitable as a shared project-context backend for multiple coding agents.

Limitations: isolation boundaries between personal, project, and team must be verified against actual configuration. You can't infer isolation capability limits from the bankId example; benchmark effects from the vendor can't be taken as guarantees for your codebase.

Ideal scenarios: engineering teams that want to continuously record project decisions, conventions, and historical experience.

Recommendation: a good candidate for the project layer; the team layer still needs explicit Bank mapping, ACL, and promotion design.

3.5 memsearch

Official references: memsearch DSH plugin · memsearch repository

Positioning: uses Markdown to save readable memory, then Milvus for hybrid keyword-vector retrieval.

Core mechanism: public docs describe capturing sessions via session/event or turn/end, writing summaries to .memsearch/memory/, reminding the agent to use memory-recall at agent/pre-step, and letting a retrieval Skill search, expand, and read memory. With no global or project config, embeddings can use a local ONNX path.

Strengths: Markdown is easy to audit, Git-manage, and migrate; Milvus provides strong retrieval scalability; good for sharing a readable memory directory across agents.

Limitations: it's more of a "memory directory + retrieval layer" than an out-of-the-box team governance system. You must verify the summary backend, Milvus address, collection naming, project path isolation, deletion mechanisms, and embedding data flow. Similarity retrieval surfaces candidates, not proof of facts.

Ideal scenarios: individuals or small teams that accept Markdown as the fact carrier and need hybrid retrieval.

Recommendation: good for the personal or project layer; the team layer needs extra evidence and permission governance.

3.6 ReMe

Official references: ReMe DSH plugin guide · ReMe repository

Positioning: lets the agent search long-term memory on demand, with automatic organization and periodic consolidation for more stable knowledge.

Core mechanism: session start injects usage guidance for long-term memory, registers a read-only reme_search tool, can commit auto_memory after turn end, and can use auto_dream to organize logs. It injects "how to use memory" guidance, not the entire history stuffed into the system prompt.

Strengths: on-demand retrieval reduces irrelevant content and token consumption; automatic organizing suits continuous accumulation of work experience.

Limitations: whether relevant history enters the current conversation depends on the agent calling reme_search. The public docs also warn that the default ReMe HTTP service has no API-key authentication and should not be exposed to an untrusted network.

Ideal scenarios: teams that want to control injection cost and accept agent-driven retrieval.

Recommendation: suitable for on-demand retrieval at the personal or project layer; before launch, test tool-call reliability and the service's exposure surface.

3.7 dsh-auto-memory

Official references: dsh-auto-memory official repo

Positioning: a zero-service, zero-embedding local DSH Memory plugin focused on readability and trustworthy writes for personal memory.

Core mechanism: memories are stored as plain files under $DSH_HOME/memory/; the index goes into the DSH prompt, plus read, search, update, and delete tools. New memories start as candidate, become verified after human confirmation; disputed and superseded stop being injected.

Strengths: local-first, few dependencies, readable files, easy to edit, Git-manage, and delete; separating candidate from confirmed states helps control wrong memories.

Limitations: verified only means personal-layer confirmation, not team-grade evidence. It doesn't natively solve cross-user clustering, de-identification, team permissions, or team version governance.

Ideal scenarios: local-first individuals who want to separate "what the model said" from "confirmed facts."

Recommendation: good for the personal layer when file auditability and a confirmation workflow matter. If you need a fully unapproved pipeline, don't make the manual confirmation path your primary option; verify whether automatic evidence checking can be connected, or switch to MemOS Local and other automatic lifecycle schemes. Team layer still needs an independent Promoter and team read-only library.

Three points readers should take away:

Its core value is readable memory, inspectable state, and retractable errors.
Personal verified cannot be promoted directly to trusted team rules.
"Automatic saving" and "usable without human confirmation as trusted" are two different capabilities.

3.8 Mnemosyne: integration pending verification

Official references: Mnemosyne official repo

Positioning: a general local SQLite memory backend direction, offering MCP, SDK, and various agent integration ideas.

Core mechanism: the official README found this round has no DSH-specific adapter or DSH install instructions, so it cannot be listed as a directly installable DSH Memory plugin.

Strengths: local, portable, good as a general memory backend direction to watch.

Limitations: DSH adapter, lifecycle hooks, data boundaries, and compatibility matrix all pending verification.

Ideal scenarios: only as a candidate backend or integration idea, not for direct DSH production selection.

Recommendation: not recommended for direct installation until a DSH adapter is verified by the official or a trusted maintainer.

4. Plugin research conclusion

Option	Auto-recall	Auto-capture	Main carrier	Layer fit	Direct conclusion
MemOS Local	Bounded auto-recall	Background capture	Local MemoryCore + Viewer	Personal	Prioritize as personal MVP
MemOS Cloud	Pre-turn search	Add after turn completes	Cloud API	Personal/Project	Compliance review first
OpenViking	`agent/pre-step`	`session/event`	Server-side context library	Project/Platform	Good for unifying Memory, knowledge, Skills
Hindsight	Injection at start	Background history absorption	Cloud / self-hosted / daemon	Project	Verify Bank and ACL mapping
memsearch	Agent on-demand	Summaries to files	Markdown + Milvus	Personal/Project	Good for auditable hybrid search
ReMe	Agent on-demand	`auto_memory`	ReMe workspace / service	Personal/Project	Test tool calls and exposure
dsh-auto-memory	Prompt index + tools	Local files	Markdown	Personal	Good for personal trusted writes
Mnemosyne	Pending	Pending adapter	SQLite / MCP / SDK	Not recommended	Verify DSH Adapter first

Conclusion: most existing plugins solve "personal memory" or "project memory." None has publicly demonstrated the complete automatic distillation of multiple people's memories into trusted team rules. So Chapter 2 doesn't keep stacking plugins; it designs a separate team governance layer.