Hermes Agent Memory Not Working: Check Save and Recall

When Hermes agent memory is not working, first confirm that the fact was actually saved, then check the profile and whether a new session loaded it. Separate those checks from retrieval: information can remain stored while the assistant fails to find or use it.

fenbs can keep a reviewed project record available to a compatible supported assistant when you restart or switch tools. fenbs does not have a listed Hermes setup guide. You can review the shared facts manually for Hermes, but you should not assume an automatic connection or transfer of its memory.

What is the quickest safe diagnostic sequence?

1. Write down the exact missing fact and the response that exposed the problem. Choose a harmless sample instead if the original contains confidential information.
2. Ask Hermes to save one short test fact using its memory tool. Inspect the resulting entry rather than accepting a promise that it will remember.
3. Identify the active profile and its memory location. Keep that profile unchanged while you test persistence.
4. Start a new session, ask for the fact without restating its answer, and compare the response with the saved entry.
5. If the fact remains in storage but the answer is wrong, test a precise lookup and ask which source Hermes used. Investigate retrieval or conflicting guidance next.

Keep the first test small. Reinstalling Hermes, changing the model, and replacing a memory provider together may hide the original cause. A single controlled example gives you evidence you can reuse when checking whether a later change helped.

Did a durable memory write actually happen?

Hermes persistent memory documentation↗ (opens in a new tab) describes MEMORY.md and USER.md under the active Hermes home’s memories directory. The memory tool changes those records. Inspect the actual entry: a conversational “I’ll remember” does not prove that a write occurred.

If the entry is missing, repeat the request explicitly and read the tool result. Was the action refused? Did the record exceed its capacity? Did it save a shorter statement with a different meaning? A failed write calls for fixing that failure before testing whether a later session can recall anything.

Check approval and enablement too. With memory.write_approval: true, saves outside the interactive CLI can wait for review: inspect /memory pending and approve a checked entry with /memory approve <id>. Disabling both built-in stores removes the built-in memory tool; listing memory in agent.disabled_toolsets also hides external provider tools. Follow the configuration section in the memory guide and restore only the access you intend.

A useful test fact might be “The Cedar sample uses the square icon.” It is distinctive and has no real-world consequence. Ask for the Cedar sample’s icon in the next session. Avoid a fact such as “our app has a login page,” which an assistant could guess without reading any memory.

Keep secrets and customer information out of diagnostic examples and screenshots. If a larger investigation needs sensitive evidence, follow your organization’s handling rules. Our agent memory security guide covers how to think about access and the contents of a durable record.

Are you using the same profile and environment?

Hermes profiles↗ (opens in a new tab) have separate home directories and state, including memory. A coding profile and a research profile can therefore hold different records on the same machine. Check the profile used by the running assistant rather than inspecting whichever memory folder you happen to find first.

Compare the environment where the fact was saved with the environment where recall failed. Note the profile, machine, launch method, and project. A terminal session and a messaging connection may not be running against the same setup. Confirm their configuration before copying files between them.

Do not solve a scope problem by giving every assistant access to every record. The goal is the right context for the right work. Keep unrelated personal and team information separate, and document the intended boundary so the next person knows what should be visible.

Did you create a new session or just restart a process?

Hermes loads a memory snapshot when a session starts; changes saved during that session reach the next session’s snapshot. Its documentation recommends /new at natural boundaries on messaging gateways. A machine restart alone can resume an existing conversation rather than demonstrate that new memory loaded.

After preserving any unfinished work, create an explicit new session and run your controlled recall test. Do not paste the answer into the new prompt. If the assistant now finds the saved fact, your original symptom may have come from testing the current conversation instead of the next session.

For ongoing work, save a short handoff before creating that boundary. State what changed, what was checked, and what remains. You should not need to depend on a long conversation staying active indefinitely. The general agent memory explanation covers this distinction between remembered information and the text currently in use.

What if storage works but the answer is still wrong?

Try two questions: a normal work request and a precise request naming the saved entry. If only the precise request succeeds, improve how the record is labeled and how the task identifies the project. Keep the fact’s name consistent with the terms you use when asking for work.

If you use an external provider, Hermes documents `hermes memory status`↗ (opens in a new tab) for checking what is active. Built-in memory and an external provider are distinct parts of the setup. Diagnose the layer containing your fact instead of assuming the status of one proves the health of the other.

Ask what evidence controlled the answer when Hermes reads a fact and still ignores it. An old instruction, an unreviewed summary, or a newer project decision may disagree with the entry. Resolve the conflict in the source record. Do not merely repeat the same instruction more strongly in another chat.

How to do this with fenbs

1. Create a free account and add the project affected by the missed memory. Start with the current goal and active task.
2. Add verified project facts as AI context notes. Put human choices in Decisions and rules, with uncertainty kept explicit.
3. Use a compatible supported assistant from Integrations, or manually review the record before giving Hermes the relevant context. fenbs does not provide a listed Hermes setup guide.
4. Save what was completed, what was tested, and the next step in Where we left off. Use that record for the next restart test and update it after continuing.

fenbs does not fix Hermes storage, search its private transcripts, or import its memory files. It is not the right tool for debugging a provider’s implementation. It helps when the project’s current work must stay understandable while you repair or replace an assistant setup.

What should you include in a useful bug report?

Include the expected fact, where it was saved, the successful write evidence, the active profile, the session boundary, and the exact recall question. Add the observed answer and whether a precise lookup worked. Remove sensitive data and unnecessary logs before sharing the report.

The Hermes overview covers the product more broadly; Copilot memory troubleshooting covers that separate assistant. For this incident, keep the diagnosis attached to one reproducible test. Explore the AI memory library after you know whether the break is in saving, scope, loading, or use.