memory-capture

Memory Capture

How every agent should write to the gutt knowledge graph: classify what you have, gate it by trust tier, make sure it isn't already there, then write one self-contained episode. This is the write counterpart to memory-search and graph-traversal (which only read) — they forward-reference it rather than restate it. Most captures are cheap; the discipline is in what you write, and whether you may write it without asking.

Hard rules (non-negotiable — read first)

1. Search before you write — and keep the ids of what you found. Run memory-search rung 1 first. If the point already exists, don't duplicate it — write a new episode with only what changed, and name the near-matches as previous_episodes on that write (rule 7). Dedup ≠ update: a near-match is a reason to write less, never to rewrite the old entry. But a near-match that contradicts what you were about to write is not a dedup — take that pair to conflict-adjudication before writing.
2. Trust-tier gate. Auto-write only Insight and Incident. Lesson, Decision, and WorkingAgreement need an explicit human signal — the user asked for it or confirmed it. No signal (you inferred it yourself) → draft it for review, don't write. Can't confidently type it → treat it as gated.
3. Keep org writes self-contained — last_n_episodes=0. Pass last_n_episodes=0 on every org/group write; the server default of 3 is wrong for plugin writes — it pulls unrelated recent episodes into entity/edge extraction. Non-zero is meaningful only in personal scope, for intentionally chaining check-ins. This bans the blind recent-N window, not provenance: naming specific related episodes is rule 7, and the two do not conflict.
4. Discover the write surface — the tool and the group. Hardcode neither. Two questions, two sources, both read at call time:
   • Which tool? Read your tool list. Depending on the deployment you'll see per-group add_memory_to_<alias> tools (pick the one for your target group; there is no group_id argument), or a generic add_memory (pass group_id to target a group), or add_personal_memory. A user who can write to 2+ groups often sees only the per-group tools — generic add_memory is hidden. Never hardcode a tool name or the mcp__…__ prefix.
   • Which group? Read the group://<group_id>/instructions MCP resources. Listing them is the discovery step: the listing is ABAC-filtered, so the group:// resources you can see are the scopes you may touch, and each payload carries the group_id to pass, a display name, and — when the deployment has filled them in — prose on what belongs in that group. group://personal/instructions is the private-scope sibling.