Changelog

V4.0 is the current SuperLocalMemory product generation. It aligns the local runtime, Python and npm packages, supported client surfaces, dashboard identity, and operational status around one governed memory system.

• Records the public SuperLocalMemory 4.0 arXiv preprint: arXiv:2608.08253, with companion Zenodo DOI 10.5281/zenodo.21853302.
• Records the dashboard identity, operational status, package metadata, and dependency-audit maintenance required for a stable release line.
• Keeps the SuperLocalMemory 4.0 research preprint correctly identified as a preprint, not a venue-reviewed publication.

Read the current GitHub release →

Agent iteration that terminates when an independent gate passes — not when the agent self-reports done. This is an AI Reliability Engineering primitive: the convergence condition is external, auditable, and queryable. Budget bounds (iteration cap, token budget, wall-clock limit) are enforced by the engine; the agent's self-report is recorded in the per-lap ledger and never consulted when deciding whether to stop.

Every lap writes a durable ledger entry to your SLM data root. All loop run history appears in the dashboard Multi-agent memory page. When the gate is an SLM recall query, a bounded loop becomes a safe multi-agent coordination primitive: one agent waits, under strict bounds, for evidence another agent has written into shared memory.

• Three surfaces: slm loop CLI · /slm-loop Claude Code command · MCP tools (slm_loop_run, slm_loop_history, slm_loop_show)
• Per-lap ledger entries persist to your SLM data root — same path as all other memories
• Loop history visible in the dashboard Multi-agent memory page without additional configuration

Nine framework-specific adapters wire the framework's native memory interface to your local SLM data root. Each adapter is a thin binding — no new storage layer, no separate service. Memories written through any adapter appear in the dashboard, CLI recall, and MCP tools.

• Each adapter stores data in your local SLM data root
• Optional SLM providers, backup, and connectors have separate, opt-in network behavior — adapters themselves make no outbound connections
• Memories written through any adapter are visible via CLI recall, MCP tools, and the dashboard

The dashboard gains a dedicated Multi-agent memory page. This is the operational layer for AI Reliability Engineering at the team level: trace which agent produced which memory, see whether loops converged or were stopped by a bound, and inspect the per-lap ledger without touching the CLI.

• Per-agent attribution — which agent wrote each memory, retrievable by agent ID
• Loop run history — all recorded bounded-loop runs, organized by loop name, with per-lap verdicts and terminal outcome
• Agent registry — registered agents and their trust signals
• Available without configuration at http://localhost:8765 (or your SLM daemon address) after upgrading to V4

A workspace (profile) now supports multiple users with explicit roles: admin, member, or viewer. Single-user setups are unchanged and require no login.

• Admin: manage users and settings · Member: read and write · Viewer: read only
• Team and access panel in the dashboard — add users, set roles, or remove members without config files
• Enable "require sign-in" (company mode) and every action is attributed to a specific person
• Tenant isolation: coordination between agents (peers, messages, shared state, file locks, activity log) is scoped per workspace
• Optional PII redaction on save — strips email addresses, phone numbers, national IDs, payment card numbers, and IP addresses before storage
• GDPR export and erasure built in