Memory floors

Three floors

Part II starts with memory because tools without durable facts re-hallucinate preferences every session. Map the floors before you write anything.

Cap as a feature

MEMORY.md and USER.md share a tight prompt budget on purpose. The cap forces durable preferences, facts, corrections, and conventions, not a dump of chat logs. Near capacity: merge, compress, drop stale lines.

Gotcha: write now, load next session

Disk updates can succeed while the current system prompt stays frozen for cache efficiency. A same-session "do you remember?" check can look like failure when the file is already correct. Verify the file, then open a new session for the behavioral proof.

MEMORY.md and USER.md

MEMORY.md is the agent notebook (environment, conventions, lessons). USER.md is your card (name, preferences, avoid-list). The agent writes them; you may edit them in any text editor. Unwritten facts do not persist.

External providers (optional)

Pluggable providers (user modeling, fact extraction, graphs) augment the built-in layer; they do not replace your files. Run one provider at a time. Switching does not migrate prior accumulation.

• Default for this course: files plus vault.
• Add a provider only when built-in memory is clearly insufficient.
• Export or note important facts before switching providers.

Proof ritual

Memory vs hallucination

Without memory the model fills gaps with confidence. With memory and sources it consults first. Still fallible, but checkable by you and by the agent.

Context window vs durable memory

The context window is session RAM. Hermes may auto-compress long threads; you can also run /context and /compress so the active prompt shrinks while the stored session remains. Prefer writing durable facts to MEMORY.md / USER.md rather than hoping a long chat will still "know" them next week.