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 system ↗

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.

• Lab: Session control studio →