/slm-bot-memory

name: slm-bot-memory
description: Cross-bot memory on a shared computer (Grok Bot, Cursor plugin, any host where several agents share one machine). Explains agent_id attribution vs. profile/scope access, how to namespace by agent_id + profile + scope, and what must never be written to memory. Read this before the first remember/recall on a new Grok-Bot-style host.
when_to_use: |
  - First session on a Grok Bot computer or any shared-bot host
  - "Will my other bots see this memory?"
  - "How do I keep this bot's notes separate from that one?"
  - Deciding whether to store something that looks like a secret or personal data
  - Setting up a second bot on a computer that already has SLM configured
allowed-tools: remember, recall, search, session_init, switch_profile

slm-bot-memory — Cross-Bot Memory on a Shared Host

SuperLocalMemory ships as an MCP server. On a single-user laptop, one bot is the only thing talking to it. On a **shared-bot host** — Grok Bot's "one computer, shared by all your Bots" model, several Cursor windows, or any setup where more than one agent process points at the same install — several agents can reach the same memory store at once. This skill is about that case: what is actually isolated, what is not, and what must never be written regardless.

---

Three things that sound like isolation and are not the same

| Setting | What it controls | Does it hide memories from another bot? | |---|---|---| | `SLM_AGENT_ID` | **Attribution** — who gets credit for a memory in logs and summaries | **No.** It is metadata, never an authenticated principal (verified in `mcp/agent_context.py`'s own docstring). Any bot that can query the same store can read a memory written under a different `agent_id`. | | `SLM_DATA_DIR` (profile root) | **Which database file** the daemon opens | **Yes.** Two bots pointed at different `SLM_DATA_DIR` values have fully separate, independent memory stores — nothing is shared unless you explicitly configure sharing. | | `scope` (`personal` / `shared` / `global`, see `slm-scope`) | **Visibility inside one store**, between profiles that share that store | Only the way you set it. `personal` (the default) stays within the writing profile; `shared`/`global` are explicit, user-initiated opt-ins. |

A memory profile (the namespace `profile_id` and `switch_profile` select) is not a fourth kind of isolation between bots. Any local caller that can name a profile can read it, and `switch_profile` moves the active profile for every bot on the computer. Treat profiles as organisation, not privacy.

The practical rule: **`SLM_AGENT_ID` tells you who wrote something; `SLM_DATA_DIR` and `scope` decide who can read it.** If two bots on the same Grok Bot computer use the same `SLM_DATA_DIR` (the common case — it is a shared filesystem, and nothing in Grok Bot's plugin model points different bots at different data directories by default), they see each other's `personal`-scope memories too, the same way two terminal sessions on one laptop would. Giving two bots different `SLM_AGENT_ID` values does not change that — it only changes whose name shows up on the memory.

If you need one bot's memories genuinely unreachable from another, that bot needs its **own `SLM_DATA_DIR`** (or a store where company mode with roles is configured — see `slm-governance`), not just its own `SLM_AGENT_ID` or its own profile.

---

Namespacing that actually works

Use all three dimensions together, each for what it is good at:

1. **`agent_id`** (`SLM_AGENT_ID` env, or the `agent_id` parameter on `remember`/`recall` directly) — so a human or another agent reading `get_memory_summary` or the stored facts later can tell which bot said what. Set it to something stable and specific: `grok_bot_support`, `grok_bot_release_notes`, not a generic `bot`. 2. **`SLM_DATA_DIR`** — the real isolation boundary. One store per bot that genuinely needs privacy from the others. A `profile_id` inside a shared store groups memories but does not hide them. 3. **`scope`** (see `slm-scope`) — inside a store two or more bots legitimately share, keep writes `personal` by default and only promote to `shared`/`global` when a fact is meant for every bot on that store.

remember(
  content="Deploy window for the support bot is Tue/Thu 14:00-16:00 UTC",
  tags="ops,schedule",
  agent_id="grok_bot_support",
  session_id="<sid>",
)

recall(
  query="deploy window",
  agent_id="grok_bot_support",
  session_id="<sid>",
)

Recall is not filtered by `agent_id` automatically — it is attribution on the written record. If you need "only what this bot wrote", pass `saved_by="grok_bot_support"` to `recall` (or `--saved-by` on `slm recall`), which keeps only memories saved by that agent id. It filters; it does not protect, because another bot can leave it out.

---

What never goes into memory, on any host

This is not Grok-Bot-specific — it is the baseline for every SLM host — but it matters more here because a shared computer means a shared blast radius if it is violated:

• **Secrets, API keys, tokens, passwords, certificates.** Never pass them to

`remember`, even "just this once" or "temporarily." If a fact needs to reference that a credential exists, store the *fact of its existence and where to rotate it*, never the value.

• **Personal data about identifiable people** that was not already something

the user explicitly asked to be remembered about themselves (names, emails, addresses, health, financial details of third parties).

• **Anything from Grok Bot's shared filesystem you did not write yourself**

and were not asked to remember. "Files are visible to every Bot" on that computer (Grok Bot's own docs) — a file being readable is not the same as having permission to copy its contents into long-term memory that other bots and later sessions will see.

• **Command-line credentials.** Grok Bot's own docs note these are shared

across bots on the computer