Memory & Context DSH plugins

Memory plugins answer two different questions. Context plugins explain what is currently in the window: composition, growth, compaction events, pruning. Storage plugins decide what survives after the window closes: graph recall, cross-session knowledge, project facts, audit trails.

Mixing the two is the usual mistake. If a plugin claims both, check whether retrieval is bounded and whether writes are approval gated, otherwise a long session slowly fills with noise.

How to choose in this category

For context tools, demand a breakdown you can act on — layers, tokens, compaction timeline — not only a single percentage. For memory stores, demand a write policy you can quote and a delete path for a wrong fact. Location matters: profile-local SQLite is a different risk than a remote multi-tenant store.

Cross-runtime claims (“works with every agent”) usually mean a bridge or a shared on-disk format. Either can be fine; know which you are installing.

What is mature versus thin here

Mature memory plugins gate writes, bound recall, and keep source-backed facts. Thin ones embed everything forever and inject a summary of the summary. Context plugins without compaction visibility are dashboards that go stale the moment the runtime compresses.

Common mistakes

Installing a memory plugin because the session felt long, without a retention policy. Treating a context meter as durable memory. Letting an unbounded graph become the only record of decisions you cannot later correct.

Install order and boundaries

Context visibility first, cross-session stores second. Memory plugins hold data about you by definition — where they store it belongs in the evaluation alongside retrieval quality. Pin versions while snapshot schemas settle.