Memory and Learning — A Toolkit That Gets Better
The Inbox: Why Subagents Cannot Write Memory Directly
One Curator, Many Contributors
If every subagent could write straight into the curated store, it would fill with near-duplicates and story-specific trivia. So the contract is split:
- Subagents drop draft JSON into
docs/.output/.state/memory-inbox/ - Only the Main Agent promotes a draft into the curated store, or discards it
node .claude/core/memory-manager.js inbox-list
node .claude/core/memory-manager.js inbox-promote <id>
node .claude/core/memory-manager.js inbox-discard <id>
Promote or Discard?
Promote an insight that is reusable across stories or projects. Discard what is project-state, specific to one story, or a duplicate of an existing memory. Curation is mandatory before a commit; drafts left in the inbox get flagged at the next handoff.
When a story forced you to backtrack, record the abandoned approach as a rejected-approaches memory before committing. The cheapest bug to avoid is the one you already fixed once.
Memory is context, not command. Injected learnings are labeled as things to consider; a memory that names a file or function should be verified against the current code before you act on it.
A subagent finishes a task and has a reusable insight. What is the correct path into curated memory?