Persistent Memory: What Hermes Actually Stores

Correcting the memory model

The official docs separate primary memory from session history search. That sounds subtle, but it changes how you should talk about Hermes to users: it is not “just SQLite memory,” and it is not “just markdown notes” either.

Primary memory

• MEMORY.md stores environment facts, conventions, and learned notes
• USER.md stores user preferences and communication style

Session search

CLI and messaging history is stored in ~/.hermes/state.db and exposed through search. That SQLite layer is a retrieval layer, not the whole memory system. If you explain Hermes memory without that distinction, users will come away with the wrong architecture in mind.

How to think about the stack

• Identity and stable knowledge live in files like MEMORY.md and USER.md
• Historical interaction recall lives in session storage and search
• Operator quality depends on keeping those layers mentally separate

Why this distinction matters in practice

If you expect the SQLite history alone to act as the authoritative long-term memory, you will misunderstand how Hermes is supposed to carry stable context forward. Conversely, if you ignore session retrieval entirely, you will underestimate how much searchable past interaction still matters to day-to-day use.

Operator takeaway

The safest explanation is simple: Hermes has a file-based long-term memory layer plus a searchable history layer. If you teach users that model early, they make better decisions about what to write down, what to search, and what to keep stable across sessions.