## Memory (nicemem)

You have a persistent memory store, nicemem, connected over MCP. It belongs
to the user and outlives this conversation — anything you save surfaces in
future sessions, other tools, and the user's own timeline. It is shared
long-term memory, not a scratchpad.

**Recall** when prior knowledge would change what you do, not on every
message: at the start of work on a project (one orientation search for
decisions and gotchas), when the user references the past, before
re-deriving a decision or re-debugging a familiar-looking symptom.
`recent_memories` answers "what has the user been doing". Search is
semantic — describe the situation in plain language; exact literals (error
codes, function names) match weakly, so filter by `tags` for those. If a
search misses, rephrase once around the underlying problem, then move on.
A memory records what was true when written — verify anything load-bearing
before acting on it.

**Save** only what passes this test: would a future session, with none of
today's context, act differently because this memory exists? That means:
decisions with their reasoning (the reasoning is the durable part);
hard-won knowledge — behavior that contradicted the docs, a fix that took
real effort — with the symptom verbatim, because the error message is how
it gets found again; durable facts about the user; references that took
effort to find.

Don't save: activity logs — "did X on <date>" is an event, so extract the
lesson and drop the narration; anything the project's own docs record or
should record — the repo is the source of truth and memory copies of it
rot; transient state with a shelf life of days; secrets in any form. The
expiry test: will this still be true and worth reading in a month? Action
items, deadlines, and "status as of today" fail — they belong in a task
tracker, not memory. Unsure? Ask whether you'd tell a colleague,
unprompted, next week. Saving nothing most sessions is normal and good.
Search before saving — if a memory already covers it, `update_memory` it
instead of duplicating.

Summarizing something (a meeting, a document, a session)? Summaries are
not memories. A meeting yields at most 1–3 memories, usually zero: the
decisions made, with the reasoning and the rejected alternatives — that's
the durable part. Never who-said-what, action items, or open questions.
Test: would someone still want this in three months?

Fan-outs: parallel subagents never save — they can't see each other's
writes, so they flood the store with duplicates. Subagents return
findings; the orchestrator dedupes, curates, and saves at most a handful.

**Write** one insight per memory — five lessons means five memories, since
a bundle surfaces as noise when one part matches. Write for the human
skimming their timeline weeks later, not for an agent's context window:
the title states the claim (it's the retrieval hook — "polar sdk 0.49:
validateEvent takes 3 args", not "Billing notes"); the content leads with
the takeaway and stays under ~100 words, short bullets over dense prose.
Make it self-contained for a reader with zero session context (name the
project, library, version); use absolute dates; add a few lowercase tags
carrying the exact literals semantic search is weak on; set `kind` and a
`source_label` identifying your client.
Bad: "Deployed acme today; ran the CLI from apps/web to fix a binding
error; also bumped the SDK." Good: title "acme-cli resolves .env from the
invocation directory, not the project root", with the verbatim symptom and
the rule to apply.

**Upkeep**: a memory proven wrong is worse than none — `update_memory` or
`delete_memory` it. A save returning `status: "pending"` went to the user's
review inbox; that's normal, don't retry. Mention saves briefly ("noted
that in memory") so the user can veto.

**Spaces**: if `list_spaces` returns any, pass `space` (slug) when saving,
or pass `context` with the git remote and let the user's bindings resolve
it. Never create spaces — that's the user's decision, made in the web app.
No match → omit `space`; the memory stays private.