/slm-recall

name: slm-recall
description: Search and retrieve facts, decisions, and past context from SuperLocalMemory. Use when the user asks to recall, find, search, or "what did we decide/say about X". Triggers multi-channel semantic retrieval with reranking; always call before storing anything new.
when_to_use: |
  - "What did we decide about X?"
  - "Recall anything about Y"
  - "Do we have context on the Z feature?"
  - "Find stored information about authentication / the database / error handling"
  - "Search for what I said about Y"
  - Automatically before any non-trivial task, to surface prior context
allowed-tools: recall, search, fetch, list_recent, Bash

slm-recall — Search & Retrieve Memory

Retrieve stored facts, decisions, and past context from SuperLocalMemory using multi-channel retrieval. The golden rule: **recall before you remember**.

---

When to use recall vs search vs fetch vs list_recent

| Situation | Tool | |-----------|------| | Conceptual or paraphrase query ("what did we agree on for auth?") | `recall` — full multi-channel retrieval + rerank | | Exact keyword match needed ("find facts containing BM25") | `search` — FTS5 BM25 only, lower latency | | You have a specific `fact_id` from a prior result | `fetch` — exact lookup, full detail | | Browse newest entries without a query | `list_recent` |

Use `recall` as the default. `search` is a fallback for zero-result recall on a known exact term. `fetch` is for when you already know the ID.

---

Recall-before-remember discipline

Before storing anything new, always call `recall` first. If a near-duplicate fact already exists, call `update_memory(fact_id, content)` to refine it rather than creating a duplicate. Duplicates degrade retrieval quality for every future session.

---

MCP-first workflow

1. Standard recall

recall(
  query="authentication strategy decision",
  limit=20,            # default 20; reduce to 5 for quick pre-task checks
  session_id="<sid>",  # pass the session_id returned by session_init
  fast=None,           # leave unset; see "Fast mode" below for what it controls
)

Real response shape (`--json` equivalent):

{
  "success": true,
  "results": [
    {
      "fact_id": "f8a2bc91",
      "content": "Decided to use JWT with 1h expiry for API auth (2026-06-10)",
      "score": 0.87,
      "confidence": 0.91,
      "trust_score": 0.84,
      "fact_type": "semantic",
      "channel_scores": {
        "semantic": 0.88,
        "bm25": 0.61,
        "temporal": 0.72,
        "hopfield": 0.55
      }
    }
  ],
  "count": 1,
  "query_type": "semantic",
  "channel_weights": {
    "semantic": 0.4,
    "bm25": 0.2,
    "temporal": 0.2,
    "hopfield": 0.2
  },
  "channel_status": {
    "semantic": "ok",
    "bm25": "ok",
    "temporal": "empty",
    "hopfield": "ok",
    "spreading_activation": "no_candidates",
    "entity_graph": "no_embedding",
    "profile": "disabled"
  },
  "incomplete_channels": [],
  "retrieval_time_ms": 134,
  "no_confident_match": false
}

**Read `channel_status` before concluding that nothing is stored.** It reports what each retrieval channel did on this query. `channel_weights` says how much each channel counts; `channel_status` says whether it ran at all.

| status | meaning | |---|---| | `ok` | the channel ran and contributed candidates | | `empty` | it ran and there was genuinely nothing to return | | `no_candidates` | it ran but nothing survived fusion | | `error` | it raised — **its results are missing from this answer** | | `timeout` | it exceeded its guard — **results missing** | | `no_embedding` | the query could not be embedded, so it could not run | | `disabled` | switched off by configuration | | `not_configured` | the backing service is not set up |

`semantic`, `bm25`, `temporal`, `hopfield` and `spreading_activation` each search and return their own candidates. `profile` is a shortcut that runs before them and can answer directly. `entity_graph` produces nothing of its own — it re-scores what the others found, by how well each result connects to the entities in your question, which is why it reports `no_candidates` when the rest come back empty.

`empty`, `no_candidates`, `disabled` and `not_configured` are normal. `error`, `timeout` and `no_embedding` mean the answer is **incomplete, not negative** — say so to the user rather than reporting "no memories found". `incomplete_channels` carries the same warning as a plain list.

**Refine on low confidence.** `recall` returns confidence signals with every result. If `no_confident_match` is `true` (or `answer_confidence` is low / `abstained` is `true`), do NOT invent a memory — rewrite the query into 1–3 more specific sub-queries (split multi-hop questions; try entity names, synonyms, or broader phrasing) and call `recall` again before concluding nothing was found. A confident match → use it directly. SLM returns fast local results (~1–2s, no server-side LLM round on the hot path) and lets you, the calling model, drive this refinement.

2. Passing session_id

Pass the `session_id` returned by `session_init`, on **every** recall in that session. It does two things.

1. **It carries the conversation forward.** Each recall offers its five best-ranked results to a small per-session working set of seven slots. A memory that keeps coming back is reinforced rather than duplicated, and the least-activated slot is the one evicted, so something referenced across several turns is hard to lose. Later recalls in the same session rank the held memories higher, and turn three is not as cold as turn one. The bias is deliberately small — it nudges the order, it never overrides an exact match. 2. **It attributes engagement to the session**, so a later `report_outcome` can close the loop on the right recall.

Omitting it costs both: recall still returns correct results, but every turn starts cold and no feedback is attributable.

**Use the real id, not a made-up one.** An id b