Memory

9.5. Search in Past Conversations

session_search — a layer distinct from condensed memory

This is the tool already mentioned in section 20.2, viewed more closely from the technical angle: every CLI and messaging session is stored in SQLite (~/.hermes/state.db) with an FTS5 full-text index. That lets the agent find specific details from conversations that happened weeks ago, even if those details were never promoted into condensed memory.

The key dividing line: Memory for facts, Session Search for full context

This is the most memorable one-line summary of section 9: Memory is for important facts that should always be present in context. Session search is for questions like “did we already discuss X last week?” where the agent needs to recover specific details from past conversations.

Returned results are raw data, not summaries

Unlike systems that rely on the LLM to summarize old conversations, as some other memory providers do, session_search returns the original messages from the database. No summarization, no shortening. The agent can scroll backward and forward in any matching session to recover the surrounding context in full.

Practical lessons

• When you need the agent to recall a specific technical decision discussed a long time ago, ask in a context-triggering way, such as “what did we decide for X before?” The agent will call session_search on its own instead of guessing or asking you to repeat it.
• For conversations containing Vietnamese, Chinese, or Japanese, FTS5 has language-specific tokenizer extensions for CJK languages, which gives more accurate search than relying only on the default English-oriented tokenizer.
• session_search works only locally against the SQLite database on the machine currently running Hermes. If you move to a new VPS without backing up state.db, following the broader backup principle in section 1.6, that searchable history is gone even if MEMORY.md and USER.md survive through separate backups.