superlocalmemory

---

Why SuperLocalMemory?

SuperLocalMemory is an enterprise-grade, local-first memory control plane for AI agents. Your team's agent memory lives on infrastructure you control, with per-workspace isolation, role-based access, and GDPR / EU AI Act governance controls — built for organizations, and for EU data-residency obligations where agent context must not leave your environment by default.

Agent-memory systems make different storage, model-provider, and deployment trade-offs. SuperLocalMemory starts with a local runtime and makes provider-backed enrichment, cloud backup, connectors, and proxy use explicit choices.

Different products solve different boundaries. The published LoCoMo benchmark evidence in this README is protocol-scoped evidence from the published V3 research architecture; it is carried forward for continuity and is not a claim of a newly rerun V4 package benchmark.

SuperLocalMemory V4 combines conventional dense and lexical retrieval with graph, temporal, associative, and statistical relevance scoring in a 7-layer control plane (admission → queryable core → enrichment → brain → multi-channel retrieval → context safety → operations). The default local runtime does not require Docker, a separately operated graph database, or an API key.

Memory with a sense of time. SLM does not only store what an agent learned — it records when. Every fact carries ingestion timing and provenance; recall runs a dedicated temporal candidate channel alongside semantic, lexical, and associative retrieval; scenes and entity timelines reconstruct sequence; and the lifecycle lets neglected memory decay and self-archive instead of growing without bound. Time is a first-class ranking and lifecycle signal rather than a timestamp column an agent never reads — which is what lets a long-lived agent reason about how its context changed, not only what it currently holds.

What changed in this release. See the CHANGELOG — every release is written up there, in plain language, newest first.

• SLM-Mesh — authenticated cross-session and cross-machine peer coordination (messages, locks, shared state, inbox/outbox, optional discovery). Coordination only — not automatic replicated memory.
• Multi-scope memory & profiles — workspaces (profiles) plus personal / shared / global scopes; cross-profile recall is default-deny.
• Cache & compression (context optimization) — exact-match cache with tagged invalidation, safe compression, and opt-in reversible/aggressive paths across proxy, MCP, and skill surfaces.
• Entity Explorer & skill evolution — compiled entity summaries/timelines; opt-in skill lineage, budgets, and verification outcomes.
• Modes A / B / C — local-only (A), on-device LLM enrichment (B), provider-assisted (C). An operating mode records technical locality facts; it does not determine EU AI Act legal compliance (that is deployment-context assessment — see Privacy controls).
• GDPR posture, retention & audit chain — export, fail-closed cross-store erasure, retention policies, and a hash-chained audit trail. Engineering controls for compliance programs, not a legal certification.
• 7-layer retrieval/recall stack & code graph — multi-channel candidates (semantic, BM25, temporal, Hopfield, spreading activation) plus optional code-graph tools for blast radius and review context.
• MCP profiles — code exposes 31 tools for installed coding agents; full 49; power 61; whole 94 (all registered). Also core (16), mesh (8), and the unrestricted default surface (49 with mesh enabled).
• Governed write path & verifiable transactions — admission + policy control, a per-owner obligation ledger, and a hash-sealed completion manifest with a reconciler that redrives unmet obligations.
• Self-healing lifecycle & admin remediation — stale locks cleared on restart; list/resolve stuck operations from CLI, MCP, or the dashboard.

SLM is one strand of Qualixar's work on AI reliability engineering: making agent behavior observable, bounded, and reproducible instead of best-effort.

The architecture evaluated in the V3 paper remains the foundation of this release. The figures below keep their original LoCoMo protocol, answer-construction, model, and sample scope.

How SLM fits beside other memory systems

Different products solve different boundaries. SLM is for developers who want one local-first operating control plane—not only an SDK, managed context API, or agent runtime. It combines dated evidence, graph-aware retrieval, cache and compression controls, SLM-Mesh, and MCP/CLI/hooks/dashboard/IDE surfaces in one install.

If your primary need is…	Product boundary to evaluate
Local-first agent memory plus operations, optimization, and IDE-agent surfaces	SuperLocalMemory — Mode A local core; Modes B/C by explicit choice.
A memory SDK, self-hosted server, or managed platform	Mem0
A temporal context-graph service or graph engine	Zep / Graphiti
A stateful agent runtime with memory blocks and archival memory	Letta
LangGraph-native memory primitives and managers	LangMem
A context API/app with profiles, connectors, and RAG	Supermemory
User profiles and event-timeline memory	Memobase

See the source-linked market comparison for current primary sources and protocol-scoped benchmark evidence. A LoCoMo percentage is comparable only when the dataset scope, answer model, judge, retrieval stack, and release artifact match.

The V4 capability architecture

SuperLocalMemory is one local control plane for persistent agent context. It is not just a vector store: the same runtime can accept evidence, build and govern memory, retrieve bounded evidence for an agent, and expose cache, compression, and SLM-Mesh peer-coordination controls through a CLI, MCP, dashboard, and supported IDE integrations.