---
name: zen-memory
description: Retrieve relevant approved facts/preferences or propose a durable scoped memory with provenance, retention reason and supersession. Use for recall and intentional long-term context.
---
# Zen memory

Keep durable context distinct from historical logs and temporary task state. Do not infer personal facts from incidental evidence.

Use an owner-confirmed communication preference to adjust explanation and detail, not authority or permission. A suggested personal mode remains a proposal until reviewed; see [personalization and reusable workflows](../zen/references/personalization.md).

## Recall

1. Identify the task/workspace and the fact or preference needed. Search MEM and applied FDK narrowly with `zen_research_search`, then read full matching records so a truncated condition is not lost.
2. Inspect status, scope, provenance, confidence, supersession and visibility. Proposed/rejected/superseded entries are not active preferences. Personal scope must be explicitly approved; workspace scope does not spread to unrelated projects.
3. Verify mutable facts when a cheap check is available. If relying on an older unverified memory, say so and label the possibility of drift. Do not substitute a remembered model/version/price for current capability discovery.
4. Return or use only the relevant portion. Show influencing refs in an agent brief. Never copy never-copy content into a summary, task, transcript or cloud record; local-only still permits a local model to read it, so it is a different boundary.

## Retain or correct

5. Decide why the information should survive this session. Keep activity/results in LOG/SES, research in RDT and exact corrections in FDK. MEM is for a durable fact/preference with a specific future use, not a duplicate transcript.
6. Create a MEM proposal with source, evidence date, confidence, applicability, project/personal scope and retention reason using [the memory template](references/output.md). Sensitive/uncertain facts and authority changes require review. Do not mark a proposed personal fact applied yourself.
7. Supersede a contradicted memory through the approved writer path, preserving both provenance and rollback. Do not delete the old memory or convert an inference into a verified fact. Check returned status before claiming application.

Use [the MCP contract](../zen/references/tools.md) or initialized [standalone records](../zen/references/standalone.md). The file-only writer retains proposed memories without automatic application. If no writer exists, return a labelled draft and explain that it is not retained.

Example: an approved project preference for concise review reports can influence that workspace's next task. A one-off command failure belongs in a log; a guessed employer or birthday must not become memory. A changed provider configuration should supersede an old note only after actual verification and the appropriate owner decision.