Tidying and measuring memory

Slate calls no model to shrink memory: the session you are in proposes and you accept. Part of Recall & Remember.

Contents#

• Tidying a project's memory
• Learning from what you decline
• When a lesson becomes a skill
• Logging progress mid-run
• Measuring it

Tidying a project's memory#

1. list_memories reads the project's memories, 100 at a time, with refs (hidden ones are not listed).
2. propose_memory_change proposes a merge (refs become one claim), a retirement (wrong or outdated refs) or a lesson (refs forming a rule about an action, with its when). Every ref must belong to that project, and none may be a memory you pinned or protected: that one is yours. A merge or lesson follows remember's save rules.
3. Each proposal waits in Memory under Needs review, with what it changes and why. Merge, Retire or Make it a lesson applies it; Dismiss drops it; Accept all applies every one, Undo reverses the batch. A memory you pinned or protected after the proposal still stays: a retirement leaves it out, and a merge or lesson naming it waits for you.

AI memory care. Turn on at the Memory care row in Memory (see Automations). Each night it reads up to 50 memories of one project or group (the largest) twice, separately, with its own agent and the code each cites, and retires only what both readings call wrong. Disagreements wait under Needs review. It shows its cost before turning on and stops at a monthly token cap you set. Each reading counts toward the cap as it ends, so a night that fails halfway still counts what it spent. A retired memory nothing replaced returns with Bring back under the retired chip for 30 days. With it on, an agent's new memory must say in reason why it changes what a future agent does.

Your own schedule. Save the Memory pass automation. Each morning it reads yesterday's sessions and up to 30 of the project's memories (pinned and cited first, then freshest, cut to a size budget) on the project's agent. It adds at most five memories and files merges and retirements under Needs review.

Learning from what you decline#

Slate keeps your no to an AI proposal: an automation's held call answered No, a step sent back, a held call denied, a run cancelled with a reason, an app card declined, a Home agent tool call skipped.

A no is never a memory alone. It becomes a proposal under Memory → Needs review when you wrote a reason (Why? (optional) beside each no) or declined the same action twice in 30 days in the same place. Accepting saves a lesson pinned to the automation, agent runs or app that produced it. At most five such proposals wait per project.

When a lesson becomes a skill#

A lesson used in at least three sessions is a way of working. Daily, at most three, Slate proposes one as a skill under Memory → Needs review. Make it a skill writes .claude/skills/<name>/SKILL.md in the project's folder, linked from .agents/skills/<name>, with the lesson and reason.

• A branch's lesson goes to the project's folder, not the worktree. A lesson with no project folder here is never proposed.
• The lesson then leaves the index (not read twice). A dismissed proposal is not asked again.
• The proposal also waits in Toolkit › Suggestions; accepting in either place writes the skill once. Other setup changes (fix, copy, remove) are only in Toolkit: Memory reviews what Slate remembers, Toolkit what agents load.

Logging progress mid-run#

log_mission_progress reports a run's work on its branch: the summary becomes a session entry of the project labelled with the branch; goal and open items become what the next session on that branch is told; each decision is a memory, with the summary as its reason. Every item passes the same rules as remember (the project's memory policy and the checks on what a memory may hold), and a reworded duplicate of a decision already kept is merged. Anything refused is listed in the reply's refused, each line naming its item and why; a refused goal or open list leaves the one already stored as it is. No doc is made. On a trunk branch (main, master, develop) the goal is unchanged. A git branch is a label on records, never a doc (ADR 0119).

Measuring it#

Does memory help? One session in four is held out: no index, lessons or tidy offer (search still works). Slate counts turns that open with a correction ("no, …", "wrong", "I told you"). The Does memory help? Activity widget (add from Edit) compares corrections per session with and without memory, after 50 sessions per group; the holdout can be turned off there.

yarn memory:report prints, from a snapshot of your store: first the cite rate (of the lessons and decisions given to a session, the share that session used; target 40%; each session and memory pair counts once, and preferences and fact memories are left out, because a session follows them without naming them); sessions that used a memory and offered memories cited, counting every delivery; offers per channel (lessons are trigger); reach per tool (work sessions given memory, of those captured); the holdout comparison (corrections per session and per 100 of your turns, for each group); health (memories written per distinct memory used; fewer is better); quality (share AI memory care read that both readings kept; aim 80%); imported memories per tool; per project, active memories, index lines and changed citations. --sample 24 writes random deliveries to judge by hand.

The index went from up to 40 short lines to 12 whole ones on 2026-11-07. To compare the two weeks on each side, run yarn memory:report --days 14 on 2026-11-07 and again on 2026-11-21.

The quality floor. A committed, synthetic store (161 memories, 19 docs, 44 questions, none of it yours) runs in the server tests and fails a push when recall or the session-start brief gets noisier. It measures precision@8, recall@5, MRR, how often a question nothing answers gets nothing back, the share of returned items that a rule must keep out (stale state, captured-session docs, title-only docs, another project's rows), the share of returned items and of brief lines that repeat another, the share of brief lines that are stale state, and that a fresh pinned state stays in the brief. A near-duplicate twin of the answer counts as an answer. The numbers are in packages/server/test/operations/memory/quality/baseline.json. Each may move one step the wrong way (one question, one returned item or one brief line) before the test fails. After a change that truly improves one, run MEMORY_BENCH_UPDATE=1 yarn workspace @slate/server vitest run test/operations/memory/quality/quality-benchmark.test.ts: floors only rise, ceilings only fall, and nothing is written while a check fails. Read the diff of baseline.json and commit it with the change. Two questions recall misses today are named as known gaps and pinned as misses. A second table test (admission-table.test.ts) pins which kind each kind of write is stored as, or why it is refused.

yarn memory:health prints the live usefulness number from a read-only copy of your store: for the last 7 days (--days N), per channel (brief, recall, trigger for lessons), the memories given to sessions, how many were judged, how many a session cited, how many still wait for their session's transcript (pending) and how many belong to no session (unowned, a screen's brief: no verdict will come), and the used share (cited over judged; a row still waiting for its transcript is not counted as ignored). Under it, the 10 most-given memories no session ever cited. A recall the session asked is judged from its transcript, cited or not. --days is a whole number from 1 to 365. --db <file> reads another store; --json prints the data. The app serves the same data at GET /memory/usefulness.

yarn memory:eval --cwd <project> runs recall on fixed questions and prints recall@5 and MRR per kind (plain, updated, time, unanswerable). The set quotes your memory, so it lives at memory-eval/questions.json in Slate's data folder. --half tune / --half report score odd / even questions; --also <file> passes other phrasings.