NEWOne memory for every agent, bot and chat windowOne memory for every agent and botWhat’s new →

Workflows

From remember to recall to a web app’s call.

Eight steps that cover a normal week with SuperLocalMemory: save a decision, get it back, start a session that already knows your rules, change your mind without losing history, and let a web app reach the same memory. Every command below is one the docs ship.

Day to day

Pick a step.

Each tab says what happens, shows the command, and lists what you get. The terminal output is from a fresh Mode A install, trimmed.

Say it once. It stays saved.

Every save moves through four durable stages: raw, queryable, enriching, complete. You get a receipt with an operation id the moment the memory is queryable. If an enrichment step fails, the raw evidence is kept and the step retries. Under heavy load a save is queued, never refused.

What you get

A receipt for every save, with an operation id you can follow.
Nothing lost on failure. A failed step keeps the raw evidence and retries.
No refused saves. Saves under load are queued instead.
A kind on the way in, when you want one: --kind decision, --kind rule.

slm — remember

$ slm remember "We deploy the API blue-green; rollback is a DNS flip." --kind decision
Queryable ✓ 1 facts (operation=ebca8e80...).
$ slm remember "Always run the migration dry-run before a release." --kind rule
$ slm remember "Staging DB is Postgres 16 on port 5433."

Real output from a fresh Mode A install, trimmed. Stages: raw, then queryable, then enriching, then complete.

Ask in plain words. See why each result won.

Recall runs its channels at once: semantic, BM25 keyword, entity graph, temporal, Hopfield associative, spreading activation and, when pictures are on, the picture channel. Their candidates are fused by reciprocal rank and reranked. Memories from your current project rank first, and nothing is hidden to make that happen.

What you get

A per-channel trace. slm trace prints the score breakdown for each result.
Project-aware ranking. Your current project’s memories rank first; --project narrows and says when nothing matched.
Filters: --project, --saved-by, --about, --kind, and exact tags with --tag.
Results never hidden. When the answer check abstains, results still come back, marked as such.

slm — recall

$ slm recall "how do we roll back the API"
  1. [0.67] We deploy the API blue-green; rollback is a DNS flip.
  2. [0.53] Always run the migration dry-run before a release.
  3. [0.52] Staging DB is Postgres 16 on port 5433.

$ slm recall "what did we decide about rollback" --kind decision
  1. [0.54] We deploy the API blue-green; rollback is a DNS flip.

# per-channel score breakdown for each result
$ slm trace "how do we roll back the API"

Scores rank; they are not probabilities. A question memory cannot answer ends in the closest memories or “That isn’t in SuperLocalMemory.”; while models load, recall says SuperLocalMemory is still warming up and to try again in a few minutes. Add --depth 0|1|2 and --max-tokens to control how much comes back.

A new session starts already knowing your rules.

When an agent opens a session, session_init hands it your confirmed rules (up to 10) and confirmed decisions (up to 5). Hooks go further: they capture decisions, bug fixes and preferences as you work, so the next session inherits them without a manual save.

What you get

Standing rules in every session. Up to 10 confirmed rules and 5 confirmed decisions load into each new agent session.
Only what you confirmed. Proposed, rejected, archived, quarantined and replaced items are never included.
Hooks for auto-capture in Claude Code and Codex, installed with one command.
One switch if you want it off: slm kinds settings --standing-rules off.

slm — session and hooks

# auto-capture hooks for Claude Code
$ slm hooks install
# and for Codex
$ slm hooks install --agent codex
$ slm hooks status

# warm context for a project
$ slm session open --project-path /path/to/project

# standing rules at session start: on by default
$ slm kinds settings --standing-rules off

Agents get the rules through the MCP session_init call. Add the universal agent rules to teach any agent when to call it.

Give a memory a kind. Replace it without erasing it.

Nine kinds tell recall what sort of thing you saved: fact, event, status, opinion, rule, decision, how-to, plan and correction. Ask “what did we decide” and decisions come first. When a fact changes, --replaces retires the old one in favour of the new: nothing is deleted, and you can undo it.

What you get

Nine kinds, and questions like “what did we decide” or “how do I” favour the matching one.
Suggestions stay suggestions. A suggested kind changes nothing until someone confirms it.
Replace, never delete. The old memory is retired, and recall returns the new one.
Undo through correction review. A rollback brings the old memory back exactly.

slm — replace

$ slm remember "Staging DB moved to Postgres 17 on port 5434." --replaces 0f57a17af3dd46e5
Replaced ✓ 1 fact(s) of 0f57a17af3dd46e5.
To undo, run:
  slm review-correction ... rollback 1
$ slm recall "which port does staging postgres use"
  1. [0.68] Staging DB moved to Postgres 17 on port 5434.

On the command line, the fact, event, how-to and plan kinds are spelled semantic, episodic, procedure and prospective.

Change your mind without losing the history.

A correction is a reviewed lifecycle, not an in-place rewrite. An edit creates a successor that stays out of current recall until a reviewer applies it; the original is kept, and a rollback restores it exactly. Every fact also records when it happened and when SLM learned it, so you can ask what was true last month.

What you get

Reviewed corrections with rollback. Apply, reject, or roll back to the exact earlier state.
Time travel: --as-of, --known-as-of (what SLM knew by then) and --valid-at (what was true then).
Windows: --window 7d, or a date range such as 2026-07-01..2026-07-31.
Two clocks kept apart. Event time and system time never blur together.

slm — time travel

# only what SLM knew by that moment
$ slm recall "staging database" --known-as-of 2026-01-01T00:00:00+00:00
No confident match.

# a saved question over the last week
$ slm view create "Work log" "what did I ship" --window 7d
$ slm view run "Work log"

Time arguments are ISO-8601. Older facts saved without a recorded time are included only if you add --include-unknown.

Your memory can say “I don’t have that.”

Relevance and “does this answer it” are different questions. After ranking, a judge looks at the top results and decides whether they actually answer what you asked. Laya runs on your Apple Silicon Mac and nothing leaves the machine. Jev runs online, on Windows, Linux or macOS, with your own key and an explicit consent box. When the results don’t answer, recall marks them abstained and your agent can say so instead of guessing.

What you get

A hallucination guard for retrieval. A confident wrong answer becomes an honest abstention.
Your choice of judge. Laya on this Mac, Jev online, or off. Only one runs at a time, and the online one never turns itself on.
Nothing hidden. Results are returned either way; your agent decides what to do.
The same verdict for a repeat question.

Read how the answer check works →

slm — recall --json

$ slm recall "<your question>" --json

# signals an agent can act on
abstained, abstention_reason
  the results do not answer the question (still returned)
no_confident_match
  nothing scored high enough to trust
answer_check_status, answer_check_ran
  whether the check ran, and why not when it did not

Pick the judge in Settings, Answer check. The online option sends the question and the top 3 memories, and only after you tick its consent.

Many agents, one memory, a clear record of who did what.

Claude Code, Codex, Cursor and Hermes can share one store. Every write records its agent through SLM_AGENT_ID, with Bayesian trust scores as a defence against memory poisoning. SLM-Mesh gives parallel sessions messages, locks and shared state. Bounded loops add the last piece: “done” means an independent gate passed, not that the agent said so.

What you get

Per-agent attribution. Filter by who saved it with --saved-by.
SLM-Mesh: mesh_peers, mesh_send, mesh_inbox, mesh_state and mesh_lock. Messages route across machines; locks and state are per machine.
Gate-verified loops. A run ends DONE, HALT, PAUSE, KILLED or ERROR, and DONE only when an independent gate (tests, a linter, a schema) passes.
Every lap stored under loop:<name> as auditable memory. Try it keyless with slm loop demo.

slm — agents and loops

# who saved what
$ slm recall "staging database" --saved-by claude-desktop

# keyless demo: a stub proposer, a deterministic gate
# (fails twice, passes on lap 3)
$ slm loop demo
$ slm loop history
$ slm loop show <run_id>

The Grok Bot and Cursor plugin writes as SLM_AGENT_ID=cursor_plugin. Attribution is not an access boundary: bots that share one data directory share one memory store.

A web app asks. Your laptop answers.

ChatGPT, Claude on the web, Muse, Composio and other HTTP MCP clients can use the same memory as the agents on your computer. The memory database never leaves your laptop. Here is the path of one call.

Turn on Web access from the dashboard, pick the profile to share, and add an app under Connected apps.
The app signs in with OAuth. You decide whether it may only read or also save.
The app’s tool call goes to the gateway, which checks the owner, the app, the profile and the tool.
The gateway relays it to your laptop over the outbound link your laptop keeps open. No port to open, no tunnel, no Cloudflare account.
SLM runs it through the same governed recall and write paths as a local agent.

What you get

Online when you are. Your laptop must be online; when it is asleep or offline, apps are told at once that it is unavailable — never handed an empty result that looks like a real answer.
A free daily allowance of tool calls on each connection, and SLM works fully without Web access.
Copy-paste instructions that tell the app when to recall and what to save. Paste the block, upload the Agent Skill, or press Copy instructions in the dashboard.
Remove any app at once from Connected apps.

Web-agent instructions →

web access — path of one call

# you, once
dashboard → Connected apps → add an app
  OAuth sign-in · read-only, or also save

# every call
app → connection gateway
  checks: owner · app · profile · tool
gateway → your laptop (over its outbound link)
laptop → same governed recall and write paths as a local agent
result → gateway → app

laptop quiet for 45 s → apps told "unavailable" at once

The memory database stays on your laptop. Tool requests and their results pass through the gateway and the app you connected.