Memory plugins round two: evolve, mnemon, core

Memory plugins have entered a second round: from "does it remember" to "how does it evolve, isolate and migrate." The three representative designs emphasize different things, and the wrong pick never errors, it just makes memory messier over time.

How round two differs

The difference is memory lifecycle, not storage.

Round one answered whether memory exists; round two answers how to govern it, at a higher cost. Once memory grows, tiering, isolation and forgetting matter more than storage. More parameters and a more complex data model mean bad configuration looks like "confused memory" or "inaccurate recall."

dsh-memory-evolve: tiers and evolution

It turns memory into a structure that evolves.

1. Tiered memory separates short-term, long-term and core layers.
2. Cross-session recall keeps project decisions reusable.
3. Evolution adjusts weights and content as memory is used.
4. Forgetting uses decay so memory does not grow without limit.
5. Isolation groups memory by namespace or workspace (source).

Tiering is the core; evolution needs parameters. Layers retain different detail: core holds stable conclusions, short-term holds transient context. Decay half-life, namespaces and sync policy all change results, and defaults may not match how often you work.

dsh-mnemon: a memory agent

It delegates curation and retrieval to an agent.

1. The agent decides what is worth remembering.
2. Retrieval selects relevant memories through the agent.
3. Structured curation reduces noise.
4. It adds one judgment call compared with plain memory plugins.
5. It suits large volumes that need organizing.

An agent cuts both ways, so check how it chooses. It filters noise but adds a model call, which may not pay off in simple setups. When its criteria are opaque, important facts go unrecorded; read the configuration and logs.

dsh-core-memory: stable conclusions

It focuses on what should not be lost, not on remembering everything.

1. Core memory holds long-term preferences and key decisions.
2. Short-term context stays out of the core layer.
3. It suits stable personas and project conventions.
4. A small store means more precise recall.
5. It is not a replacement for a full memory store.

Core memory is small and stable, which pairs well with tiered plugins. It does not keep every detail; it protects what matters. Put stable content in the core and transient content elsewhere, because used alone it looks like it remembers too little.

Running them together

Technically possible, practically discouraged.

1. Multiple injections: recall results stack, the same fact is retrieved several times, and context is wasted.
2. Duplicate writes: the store grows into several copies, complicating deletion and migration.
3. Unclear diagnosis: you cannot tell which plugin produced a result.

Pick one primary memory and give it a week. When you need more capability, choose the broader plugin instead of stacking. Memory effects need time; constant switching never shows a stable outcome.

Data location and migration

Switching plugins does not move memory.

1. Locate the data: local files, a directory, or a database; prefer implementations with JSON export.
2. Back up before import: avoid overwriting existing memory.
3. Verify after migration: ask about details from an old session.
4. Keep the old data briefly: remove it only after confirmation.

Migration depends on readability, and backups should cover the whole directory. Encrypted or proprietary formats are hard to move; check export support when choosing. Copying a single file can drop indexes or attachments.

Choosing one

Decide by volume, whether you need tiers, and whether curation matters.

Prove the flow before upgrading, not for the feature list. Round-one plugins solve most recall problems; move to round two when evolution and isolation are genuinely needed. More parameters cost more configuration, and unused capability is just weight.

Troubleshooting

Memory failures cluster into four classes.

1. Nothing remembered: switch off, wrong namespace, or failed write.
2. Wrong memory: recall treats an old conclusion as new; check evolution and priority.
3. Slower over time: the store grew and recall scope is too wide; tune decay or clean up.
4. Lost after switching: incompatible format or changed path; follow export and import.

Start from write logs and recall records, then test small. Seeing what was written and retrieved beats reading interface hints. Test with one project and one namespace before widening.

Next steps

Set memory volume first, then tiers and isolation. For round one, read Which dsh memory plugins exist. For a comparison, read How to choose a memory plugin. For memory that fades, read What dsh-fish-memory is.

Sources: dsh-memory-evolve plugin page (piaobo123), dsh-memory-evolve plugin page (brianwang2007xjtu), DeepSeek Harness documentation