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. On Hermes Agent v0.20 or newer, run /context first. Its category table separates system prompt, tools, skills, memory, conversation, and free space; /context all adds per-skill and per-toolset costs. Use /usage for provider usage and cost. If Hermes Desktop no longer shows the meter after an update, right-click the bottom status bar, enable Context meter, and wait until the chat has usage data. A hidden widget is not proof of deleted memory. 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. Current Hermes uses in-place compression by default: the active session keeps its ID while pre-compression turns are soft-archived for history. Older lineage-style continuation behavior can still appear in legacy sessions or when in-place mode is disabled, so do not diagnose a missing #2 session as compression failure.

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.

Hermes repeats tools or answers before context is full#

A loop at low context occupancy is not the same as context exhaustion. /context shows the active prompt breakdown and free space. /status shows session-level model, profile, token, and duration information; do not treat a cumulative session counter as the model payload for the next turn. A recent support case looped around 39K tokens on a 64K model, while the underlying causes were separated into a Hermes restart-loop bug and model-side tool-selection behavior.

Use one-variable-at-a-time checks:

/context
/context all
/status
/model
/tools list

1. Check pressure. If /context still shows substantial free space, do not keep forcing /compress.
2. Check inventory. /context all and /tools list prove which skills and tool schemas are loaded. Missing or duplicated capability is a tool configuration problem, not durable-memory corruption.
3. Update and isolate. Run hermes update, then start /new loop-test so an already-damaged session does not contaminate the test.
4. Replay one tiny action. Ask for one tool call with an observable result. If the same model repeats the call or never consumes its result, switch only the model or provider and run the identical test again.
5. Classify the result. A fresh-session fix points to old session state; an update fix points to Hermes runtime behavior; a model-only difference points to tool-use compatibility. If every route fails, inspect logs and the tool definition before changing memory.

For local models, verify the effective context length and tool-calling support rather than relying on the model's advertised maximum. The local model guide and provider fallback guide provide the next checks. Preserve the exact repeated call, error, model, provider, and Hermes version in a session handoff before resetting a long job.

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 /context, use /context all when skills or tool schemas look expensive, and use /usage for provider consumption. Reduce a long thread with /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.

A missing session may be hidden by its surface, not deleted#

Before repairing memory or SQLite, identify the session source. In Web UI, select the profile that owns the conversation and change Chats to Automation or All; cron, tool, API, and ACP sessions are filtered from the default human-chat view. Bot Mode is different: each bot's canonical Bot Chat is intentionally kept out of the regular Sessions list and must be reopened from the Bots roster. The eye icon restores a hidden bot row, not its chats. A separate chat created with New chat with this agent can appear under Sessions. Use the Hermes Dashboard Sessions guide, then compare the UI with hermes sessions stats and FTS5 search before attempting storage repair.

Check the auxiliary provider when compression fails#

A healthy main chat does not prove compression or session search has a funded route. Inspect auxiliary.compression and auxiliary.session_search, confirm their provider/model/wallet, and test them after any provider change. Repeated compression failures can look like memory loss while the real cause is a 402, 429, timeout, or output limit on a side lane. Follow the provider error decision tree before deleting memory or resetting sessions.

Memory is full: consolidate instead of deleting the store#

Built-in memory is deliberately bounded: MEMORY.md allows 2,200 characters and USER.md allows 1,375. When an add or replace would exceed the limit, Hermes returns the current entries and asks the agent to consolidate; it does not silently evict an older fact. A full store is therefore a curation problem, not a reason to delete state.db, raise the context window, or install another provider.

hermes journey list
hermes journey edit memory:memory:0
hermes journey delete memory:memory:3

Use the §-separated entries shown by the memory tool to merge overlapping project facts, remove stale one-off details, and retry the original write in the same turn. Keep raw logs and old task narratives in session history. The memory setup guide explains what belongs in each store; the session handoff checklist preserves current project state without consuming permanent memory.

Wrong memories keep returning: audit automatic writes#

Hermes can run a background self-improvement review after a turn. That review may save a memory or update a skill, which is useful until a weak assumption is promoted repeatedly. Turn on the write gate before deleting files:

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

Set display.memory_notifications: verbose when you need a compact preview of each automatic change. If unwanted saves stop after memory.write_approval: true, the store is healthy; the problem was write policy. If they continue, verify the active profile and external provider, because the built-in gate and an additive provider have different write paths.

The background review also has its own cost and failure lane. Inspect auxiliary.background_review, provider credits, and session_model_usage entries where task='background_review'. To isolate a suspected review loop without disabling manual memory or /refine, set auxiliary.background_review.enabled: false, start a clean test session, and compare behavior. The provider cost and rate-limit guide covers 402/429 and auxiliary-route failures.

Fresh community signal: inspectability beats more memory layers#

Recent Hermes community discussions are converging on the same failure mode: users add a semantic provider or wiki because recall feels weak, then discover that irrelevant injection, duplicate facts, unclear identity mapping, or profile-scoping mistakes make the agent less predictable. A current Reddit discussion about irrelevant Honcho context and a local-first memory-provider discussion both emphasize visibility, provenance, and correction. Treat those threads as problem-language evidence, not official setup instructions.

The operating rule is simple: prove built-in memory in one profile, turn on write approval, inspect what is injected, and only then add one external provider for a named capability. More retention is not automatically better recall.