Tool
Hermes Memory Viewer — Browse & Search Agent Memory
Inspect Hermes memory with hermes journey, built-in MEMORY.md and USER.md, dashboard profile checks, and SQLite FTS5 session search.
Quick answer
Use `hermes journey list` to inspect learned memory and skill nodes, `hermes journey edit <node>` to correct one, and `hermes journey delete <node>` to remove stale state. Built-in MEMORY.md and USER.md are bounded durable facts; full conversations live separately in `~/.hermes/state.db` and are searched with FTS5. Verify the active profile before changing either store.
Hermes memory is inspectable by design. A viewer turns the on-disk MEMORY.md, summaries, and FTS5 index into something you can browse, search, and audit when the agent recalls the wrong thing. Use `/context` for the separate live prompt window; a memory viewer cannot diagnose tool schemas, skills, or conversation pressure.
Features
- ✓hermes journey timeline
- ✓Memory node list, edit, and delete
- ✓Profile-scoped MEMORY.md and USER.md
- ✓FTS5 session search
- ✓Dashboard profile verification
- ✓CLI JSON export
Why this tool matters
Hermes exposes its learned state through `hermes journey` (aliases: `hermes learning` and `hermes memory-graph`). The timeline combines saved skills and memory nodes; list, edit, and delete subcommands make correction explicit rather than hiding it behind a model-generated summary.
Built-in durable memory lives under the active HERMES_HOME in `memories/MEMORY.md` and `memories/USER.md`. Full conversations, tool calls, session titles, and FTS5 history live separately in `state.db`. A trustworthy viewer must label those stores instead of presenting one blended memory bucket.
Always prove the active profile before editing. Default and named profiles have different Hermes homes, and Bot Mode or gateway sessions may not use the profile currently selected in a local CLI or dashboard.
Memory writes are bounded and reviewable. Enable `memory.write_approval`, inspect staged entries with `/memory pending`, and use verbose memory notifications when auditing automatic background-review saves.
Best use cases
FAQ
Under ~/.hermes — Markdown files like MEMORY.md plus an FTS5 full-text index. A viewer reads that same on-disk state, so it shows exactly what the agent retrieves.
Retrieval quality depends on what the agent chose to save and how it searches. A viewer lets you confirm whether a fact exists in the store and whether stale context is being pulled, which is usually the real issue rather than 'forgetting'.
The built-in journey view reads profile-scoped local memory and skills. Optional external memory providers have their own storage and network behavior, so audit the active provider with `hermes memory status` before treating the whole memory stack as local-only.
Run `hermes journey list`, then `hermes journey edit <node>` or `hermes journey delete <node>`. Verify the active profile first because each profile has its own Hermes home and memory.
No. MEMORY.md and USER.md hold compact facts injected at session start. SQLite state.db holds full conversations and powers FTS5 session search. A viewer should label both stores clearly.