Memory
- 9.1. User Profile — A Profile of You as a Person
- 9.2. Work Conventions
- 9.3. Technical Environment
- 9.4. Inter-Session Reminders
- 9.5. Search in Past Conversations
- 9.6. Classification and Memory Management
9. Memory — Hermes’s Four Layers of Memory
This section goes deeper into the mechanism mentioned briefly in 20.1/20.2. The key point is this: Hermes does not have one memory system. It has four distinct layers, and each layer serves a different kind of information. Most confusion when using Hermes comes from treating all four as if they were the same thing.
Four layers, four roles
| Layer | Stored where | Role |
|---|---|---|
| USER.md | ~/.hermes/memories/USER.md | A profile of you as a person (9.1) |
| MEMORY.md | ~/.hermes/memories/MEMORY.md | Work conventions + technical environment (9.2, 9.3) |
| Nudge mechanism | integrated into the session flow | Prompts the agent to save things across sessions (9.4) |
| session_search | SQLite FTS5 ~/.hermes/state.db | Looks up old conversations when needed (9.5) |
The principle of deliberate limits
Both USER.md and MEMORY.md have hard size caps: MEMORY.md ~2,200 characters (~800 tokens), USER.md ~1,375 characters (~500 tokens) — around 1,300 tokens total for everything Hermes “remembers about you,” injected into every prompt of every session. This is not a random technical limit. It forces the agent to keep compressing and distilling, preventing the “infinite memory” failure mode where the agent becomes expensive, slow, and oddly fixated on some detail you mentioned months ago.
Frozen snapshot — the rule that runs through 9.1–9.3
Both files are loaded as a frozen snapshot at the start of the session. Changes written during a running session are saved to disk immediately, but they do not appear in the system prompt until the next session. This is a deliberate tradeoff to keep the model’s prefix cache stable and avoid API costs spiking every time memory changes mid-session.