Hermes Agent Memory Troubleshooting: Fix Context, Drift, and Recall

When Hermes seems to forget a fact, mix two projects, lose the thread after compression, or recall the wrong conversation, first identify which state layer failed. Active context, durable memory, session history, external memory providers, and profiles are separate systems. Fixing the wrong layer usually makes the problem harder to diagnose.

Diagnose the right memory layer first#

Hermes has four practical state layers. They solve different problems:

1. Active context is the conversation currently sent to the model. It is finite and eventually needs compression.
2. Durable memory stores compact facts and preferences in MEMORY.md and USER.md. It should not become a task diary.
3. Session history stores full conversations in SQLite and powers resume plus FTS5 session search.
4. External memory providers add semantic retrieval or user modeling alongside built-in memory. Only one external provider is active at a time.

Profiles wrap those layers in an isolation boundary. A CLI session under the default profile and a Telegram gateway under another profile can both be healthy while remembering different things. The persistent memory overview explains the architecture; the memory setup guide covers a clean first configuration.

Memory troubleshooting decision tree#

Hermes forgot something from the current conversation#

Check context pressure before editing memory. Run /usage, then use:

/compress

For more control, /compress here 2 keeps the latest two exchanges verbatim and summarizes the earlier conversation. A focused command such as /compress deployment decisions asks the summary to preserve one topic. Compression creates a continuation session; titled sessions receive lineage names such as project #2 and project #3.

Use /new only when you want a genuinely fresh session. If compression repeatedly fails, inspect the active provider and its context window with /provider, /model, and /usage. A provider quota or model-context failure is not a corrupt memory store. The provider rate-limit guide separates quota errors from context errors.

Compression keeps timing out or retrying on every message#

A failed compression call is often an auxiliary-model problem, not lost memory. First update Hermes, then give compression a route that is fast enough and has a context window at least as large as the main agent model:

hermes update
hermes config edit

auxiliary:
  compression:
    provider: nous
    model: gemini-3-flash
    timeout: 180

You can also add auxiliary.compression.fallback_chain when one route is likely to hit credits, payment, or capacity errors. Do not choose a tiny-context summary model merely because it is cheap: the compressor sends the middle conversation to that model, and an undersized context window can fail at exactly the moment you need recovery. After changing the route, use /compress here 2 to keep the latest two exchanges verbatim and summarize the rest. The context compression setup guide covers thresholds, model routing, and failure checks.

Hermes forgot a stable fact between sessions#

Run:

hermes profile list
hermes profile show <name>
hermes memory status
hermes config path

Then confirm the active profile has:

memory:
  memory_enabled: true
  user_profile_enabled: true

Built-in memory is loaded as a frozen snapshot at session start. If memory was written or edited during the current session, start /new memory-check before concluding the write failed. Test with one harmless fact, not a password or API key.

Durable memory is intentionally small. Use it for stable environment facts, preferences, conventions, and lessons likely to matter again. When it is near capacity, consolidate overlapping entries instead of adding another verbose paragraph. Store secrets in the profile .env or a secret manager, never in memory.

Hermes cannot find an older task or decision#

Do not copy every transcript into durable memory. Name important sessions and search the session store:

hermes sessions list
hermes sessions browse
hermes --continue "project name"

Ask Hermes to search past sessions when you need a specific discussion. Session search returns actual stored messages from ~/.hermes/state.db; it is different from the compact facts injected into every prompt. Search is cross-session and can cross CLI, Telegram, and Discord history when those sessions belong to the active profile; the /sessions picker itself may be more narrowly scoped by origin. Use the AI agent session handoff checklist when a project must continue safely across people or long gaps.

/sessions looks empty or session search misses an older message#

Do not assume the database is corrupt from one empty picker. On messaging platforms, bare /sessions can be scoped to the current origin, shows named sessions, and excludes the active session. /sessions full includes unnamed sessions for that origin. Check the store before attempting repair:

hermes --version
hermes sessions stats
hermes sessions repair --check-only
hermes sessions list

If sessions stats still reports sessions and messages, ask Hermes to search one exact phrase with an explicit time direction, such as “search past sessions for deployment checksum, oldest first.” Session search uses FTS5 relevance by default, so a newer match may rank above an older one; that ordering is not proof the old session vanished.

An automatic session reset also does not delete the prior session. It rotates the channel to a new session ID while leaving persisted messages available to session search. A request that fails before it is appended can be absent, but that does not erase earlier stored turns. Back up before any real repair, and use the session handoff checklist to preserve the current goal, files, and verification evidence before resetting.

Hermes recalls the wrong fact or drifts#

Turn on approval before allowing more automatic writes:

/memory approval on
/memory pending
/memory approve <id>
/memory reject <id>

The equivalent config is memory.write_approval: true. This stages foreground, gateway, and background-review memory writes for review. Reject incorrect assumptions, consolidate duplicate entries, and keep the store concise. The optional dashboard can help inspect the active profile and operational state; see the Hermes Dashboard and Web UI guide.

A June 2026 Discord support snapshot contained threads titled “Severe memory bleed, hallucination, and drift,” “Context mixing between conversations,” and “Built-in memory docs say Hermes consolidates when full.” That snapshot is historical rather than proof of current incidence, but it reinforces the same operating rule: inspect and gate writes instead of treating every wrong answer as model randomness.

Memory works in CLI but not Telegram or Discord#

This is usually a profile or process boundary, not a memory algorithm problem.

1. Confirm the active session profile with /profile; use hermes profile show <name> for profile details.
2. Inspect the gateway profile/config and run hermes gateway status.
3. Restart the gateway after config or profile changes.
4. Send one real message through the target channel.
5. Check gateway logs if the channel still behaves differently.

The gateway troubleshooting guide covers stale processes, duplicate polling, launchd/systemd state, and end-to-end delivery checks. Use distinct profiles and bot tokens when two bots need different memory, skills, or secrets.

An external memory provider caused the problem#

Return to the smallest known-good setup:

hermes memory status
hermes memory off

Start a fresh session and verify built-in MEMORY.md and USER.md first. Then re-enable one provider with hermes memory setup and test again. External providers are additive; Honcho, Mem0, Hindsight, OpenViking, and other provider failures should not be debugged as if they were built-in memory corruption.

If an Obsidian workflow is involved, remember that the vault is a human-readable note surface, not a replacement for session state or durable memory. Follow the Hermes Agent Obsidian workflow and verify the gateway can access the same filesystem path as the CLI.

Safe repair sequence#

Use this order so each test answers one question:

1. Record the symptom. Missing current detail, missing stable fact, wrong past session, cross-project bleed, or provider error.
2. Prove the profile. Run /profile on the surface that failed; use hermes profile show <name> when you need the profile home and details.
3. Prove built-in memory. Run hermes memory status, disable the external provider, and start a fresh session.
4. Inspect context. Run /usage; use /compress, not the nonexistent /compact alias.
5. Search history. Resume or search sessions instead of promoting temporary task logs into memory.
6. Gate new writes. Turn on memory approval while correcting drift.
7. Test the real surface. A CLI answer does not prove Telegram, Discord, cron, or a remote gateway uses the same profile.
8. Back up before surgery. Use the Hermes memory backup guide before pruning sessions or editing state files.

When to use FlyHermes instead#

Self-hosted Hermes gives you direct control over profiles, local memory files, providers, gateway services, backups, and update timing. That control also makes you responsible for process uptime, disk state, profile boundaries, remote access, and recovery.

If the outcome you want is an agent available from browser and phone without operating that stack, compare FlyHermes managed hosting. Managed hosting does not eliminate the need for sensible memory boundaries, but it removes much of the VPS, gateway, TLS, update, and monitoring work around them. The self-hosted vs hosted AI agent guide gives the full decision framework.

Persistent state is not persistent execution#

Memory and session state can survive a restart, but they do not execute work while the runtime machine is asleep. Separate recall problems from uptime problems: inspect context and memory for the former, then run a closed-client scheduled test for the latter. See the self-hosted vs hosted AI agent guide for the runtime ownership checklist.