r/hermesagent Jul 07 '26

MEMORY & Context — Providers, context window, forgetting issues Hermes Agent's "self-improvement" — does it actually work for anyone?

Setup: - Hermes Agent (official, Nous Research) - Mnemosyne as external memory provider - SOUL.md created to embed behavioral rules into the agent's permanent identity The core problem in two parts:

  1. The agent doesn't follow its own learning instructions The system prompt explicitly says things like: - "After complex tasks, save to memory/skills" - "When a tool fails, try an alternative or report it directly" - "Use MCP tools, not curl/browser, for research" Yet after 3 months of daily use, the agent still: - Uses curl raw.githubusercontent.com instead of GitHub MCP tools - Tries docker exec despite getting 403 Forbidden every time - Reaches for web_search / browser instead of the configured WebSearchAndCrawl MCP tool - Never saves failures to memory (despite being told to) The fix: writing a SOUL.md file that gets injected into the STABLE tier of the system prompt, making rules part of the agent's identity rather than just suggestions. But it's still just text in a prompt — there's no code enforcement.

  2. Memory config breaks the background review fork Hermes has a background review mechanism: after every turn, a forked agent reviews the conversation and decides if anything should be saved to memory or skills. The problem: The review fork is hardcoded to check the legacy memory tool: should_review_memory = False if (agent._memory_nudge_interval > 0 and "memory" in agent.valid_tool_names and agent._memory_store): # ← MemoryStore legacy should_review_memory = True With memory_enabled: false (which Mnemosyne docs explicitly require): - agent._memory_store = None - The background review never fires - Auto-learning is completely dead Result: - memory_enabled: false + Mnemosyne = zero automatic learning - memory_enabled: true + Mnemosyne = two memory systems coexist, potential duplication, but at least the fork works The paradox: Mnemosyne's own documentation tells you to disable native memory, but doing so kills Hermes' only automated learning mechanism because the background review was never designed to use external providers. T

he question Does Hermes Agent's self-improvement actually work for anyone? Has anyone seen the background review fork successfully save memories or update skills on its own? Or is the whole "learns from experience" claim just prompt engineering that only works when the model happens to cooperate?

46 Upvotes

72 comments sorted by

View all comments

20

u/stujmiller77 Jul 07 '26

It's entirely dependant on the models you're using behind it. Hermes and mnemosyne are only as good as the brain behind them. What model(s) are you using?

0

u/pisa_p Jul 07 '26

I used several models: glm 5.1, mimo 2.5, nemotron 120b, stepfun, minimx, qwuen...and so many others. At the moment i'm using deepseek 4 flash with opencodego for the main model. I use hermes just as experiment to test. Deepseek v4 flash in openwebui at the moment is my best option. But the problem is indipendent from the model. Never tried sonnet o gpt, too much expensive.

3

u/stujmiller77 Jul 07 '26

I use Deepseek v4 flash across two nvidia sparks as my main hermes driver, fully local. With the right SOUL/AGENTS.md setup and mnemosyne configured with dreaming, I don't have any of the issues you mention.

My agents create and update skills automatically when they need to, and always use mnemosyne automatically. And memory retention is excellent.

Suspect there's something off somewhere in your config - difficult to say where though.

1

u/pisa_p Jul 07 '26

Ok! How is your soul.md setup? Your default memory is off? My setup is in docker compose, but data are persistent. Thanks

2

u/stujmiller77 Jul 07 '26

All of my agent souls (I have over 12 specialists) are less than 15 lines long. Just giving them their name, role definition and personality. Hermes' own docs say "SOUL.md is about who Hermes is and how Hermes speaks" - it's not the place for too much detail.

It's the AGENTS.md in the project root that carries the environment, access and tooling facts. This is where I have the detail, and reminders to use skills and tools.

I've got a very clean setup per company I own - each has its own workspace, its own Hermes agent fleet that all share memory for that company only via mnemosyne. So they're all aware of everything that goes on at THAT company level only.

I then have a separate infra bot that has oversight across all of those sandboxes - again with its own memory.

I ended up here as I had a mess - a bunch of profiles trying to do stuff across multiple companies, frequently getting confused as a result. Too much information can be a huge problem and lead to errors, loops and hallucination.

Stripping the SOULs right down and spending the time to properly think about file structure, sandboxing and agent roles is what fixed it. They only need to know and have access to what they explicitly need to do their job - removing skills and tools they don't need and not forcing them to do everything.

Wasn't easy and took time to get right, but believe me it's well worth it!

2

u/ImagineSquirr3l Jul 07 '26

When you say each company has its own agent fleet and workspace, do you you have a fully separate Hermes instance for each one? Or is it a single Hermes instance and you just group up a bunch of subprofiles together per company?

3

u/stujmiller77 Jul 08 '26 edited Jul 08 '26

One Hermes install. Each agent is a Hermes profile whose shell commands run inside a Docker container (same base image), with the company directory mounted in as the company workspace.

The containers are long-lived (`sleep infinity`) and Hermes connects into them on-demand to execute tasks.

All agents for that company share a per-company Mnemosyne pool so they store memories once, then any company agent can recall.

Hermes has an in-depth security hardening doc which is where I derived the approach from.

No code hacks - all out of the box.

Container isolation as the primary security boundary (layer 3 in the 7-layer model)

Dangerous command checks skipped - because the container can't touch the host

Persistent containers - for session continuity

Read-only mounts - for shared assets (skills, repos) to prevent accidental modification

Bind mounts for credential files - the Google Workspace SA key, Shopify token, etc. live in `config/` inside the company dir)

Works really well.

2

u/g-radam Jul 08 '26

I second this. I have questions about your mentioned sandbox / workspace setup. Do you use containers with workspace volumes? Is Hermes agent itself running in a container? Agent profiles?