Skip to content
Flows
Memory & Context Intermediate · 60-90 minutes

Memory Write Policies

Decide what gets remembered: write gates, provenance, confidence, and validation - because memory quality is set at write time.

Start Route · 4 steps

The route

4 steps to Done

  1. 01

    Write the memorability criteria

    The gate is a checklist, not a vibe.

    Preview prompt + verify gate ▾

    Define the write gate. MEMORABLE: durable project facts, user preferences stated or clearly implied, decisions with reasons, working recipes verified by success, failures with diagnosed causes. NOT MEMORABLE: ephemeral state (current file open), one-off values, anything reconstructible from the code in seconds, speculation, and secrets (hard block: credentials never enter memory). For each memorable type define required fields (e.g. a recipe requires the command AND the context it worked in). Encode this as the memory tool's validation spec and as guidance in the system prompt. Test the gate with 10 candidate writes (5 should pass, 5 should be rejected) and verify each outcome.

    • Memorable and not-memorable lists concrete
    • Secrets hard-blocked
    • 10-candidate test matches expectations
  2. 02

    Attach provenance and confidence

    A memory without provenance is a rumor.

    Preview prompt + verify gate ▾

    Extend the memory entry schema with metadata: {content, type, provenance: {session_id, date, evidence: 'user-stated' | 'observed-success' | 'observed-failure' | 'inferred'}, confidence: high | medium | low, last_confirmed}. Rules: user-stated preferences and observed successes/failures start high; inferences start low; confidence rises when a later session re-confirms (update last_confirmed) and falls when related actions fail. Update the write tool to require metadata and the read path to render it compactly (e.g. a [high, user-stated, 2026-07] suffix). Backfill existing entries with best-effort metadata, marking unknowns explicitly.

    • Schema enforced on new writes
    • Evidence types drive initial confidence
    • Existing entries backfilled honestly
  3. 03

    Detect and resolve contradictions

    Two contradicting memories is a bug with a deadline.

    Preview prompt + verify gate ▾

    Implement contradiction handling on the write path. Before storing, compare the new entry against same-type entries (normalized keyword overlap, or an LLM check for semantic conflict on candidates). On conflict: (a) if the new entry has stronger evidence, supersede - archive the old entry with a superseded_by link; (b) if weaker, reject the write citing the existing entry; (c) if equal and incompatible, store the new one as 'disputed' and flag for user confirmation at the next natural moment. Never silently keep both as normal entries. Test with three scripted conflicts covering all three outcomes and inspect the store after each.

    • Conflict check runs on every write
    • Supersede keeps an audit trail
    • Disputed entries flagged for the user
  4. 04

    Add quarantine and prove write quality

    Single observations are hypotheses, not facts.

    Preview prompt + verify gate ▾

    Implement quarantine and run the quality test. Quarantine: low-confidence writes go to a pending area excluded from default session loading; a second consistent observation promotes them to the main store (evidence upgraded); a contradicting observation deletes them; entries idle past a TTL (default 14 days) expire. Quality test: run a scripted week of sessions producing 30 candidate writes seeded with trivia, one contradiction pair, two secrets, and repeated observations of one inference. Verify: trivia and secrets rejected, the contradiction resolved with audit trail, the repeated inference promoted from quarantine, and the final store contains only justified, metadata-complete entries.

    • Promotion requires a second observation
    • TTL expiry works
    • Final store audit shows only justified entries

Research-backed

Sources behind this flow