Memory tiers

Hermes memory is Kanade-owned local memory. It is stored as markdown plus a SQLite/FTS index under the configured memory directory, then recalled into turns only when it is useful for the current project and prompt.

v0.5.0 adds tiers so every remembered item carries a job:

Tier	Use	Dispatch behavior
core	Durable project instructions and load-bearing user feedback.	Injected as a distinct project-instruction block when the project matches.
recall	Working memory: facts, decisions, and recent useful context.	Retrieved by FTS, project match, recency, and frequency.
archival	Older state that should remain searchable but not crowd normal turns.	Returned only when queries ask for it or the UI filters to archival.

Core memories are intentionally scarce. They are the things a future lane should obey before it starts generating code: repository rules, release proof rules, project-specific commands, and durable preferences. Recall memories are more fluid. They help answer “what did we decide?” without becoming instructions. Archival entries keep history available without making every turn heavier.

How recall is scored

The daemon combines SQLite FTS hits, project match, recency, and use frequency. API responses expose a score, score breakdown, source, tier, and a short “why” string so operators can see why a memory appeared. The /memory route can query approved memories and filter by tier.

Promotion and pruning

Memory starts as local evidence: transcripts, explicit commands, approved proposals, or imported markdown. It becomes trusted only after review. When a memory no longer belongs in normal recall, archive it instead of deleting it. Deletion should be reserved for wrong, sensitive, or obsolete entries.