Durable State ≠ Model Context: What Hermes Agent's Mid-Session USER.md Edit Actually Revealed

I changed Hermes Agent’s USER.md while a session was still running. The file changed immediately. The next model request didn’t. It still carried the old user profile. Then I compressed the session. Same session ID, but the prompt rebuilt with the new profile. This matters because “state changed” does not mean “the model saw the change.” In a production agent, that gap can create stale decisions, confusing debugging, and false confidence that a correction is already active. That experiment exposed a boundary I think matters well beyond Hermes: durable state ≠ current model context. The same thing showed up elsewhere. A nested AGENTS.md rule arrived through a tool result without rebuilding the system prompt. A loaded skill entered conversation history rather than the prompt snapshot. And provider-cache state was separate again. Part 2 of Hermes Agent Architecture traces those boundaries through prompt assembly, context files, skills, caching, and compression. I also published the reproducible lab and validation receipts for anyone who wants to test it on another provider, or Hermes release.

This one checks out closely against Hermes Agent's own documentation — it's a legitimate, technically precise finding, not hype.

Confirmed accurate:

• USER.md is indeed part of the "volatile" tier of the system prompt, alongside memory snapshots and session metadata.Volatile: Memory snapshots (MEMORY.md), user profiles (USER.md), external memory provider blocks, and session metadata DeepWiki
• Mid-session file edits genuinely don't retroactively mutate an already-built cached prompt — this is documented, intended behavior, not a bug the poster stumbled onto.Mid-session writes update disk state but do not mutate the already-built cached system prompt until a rebuild path runs (new session, or explicit invalidation/rebuild flow such as compression-triggered rebuild) GitHub
• Compression as a rebuild trigger is explicitly named in the docs — matching the poster's exact experiment (same session ID, new profile appears only after compression). a rebuild path runs (new session, or explicit invalidation/rebuild flow such as compression-triggered rebuild) GitHub
• AGENTS.md is loaded at session start into the context tier, not dynamically re-injected via tool results as a matter of standard flow — so a nested AGENTS.md rule "arriving through a tool result without rebuilding the system prompt" is consistent with the documented separation between the cached system prompt and per-turn plugin/tool context. pre_llm_call plugin context also lands in this API-call-time path: it is appended to the current turn's user message, not written into the cached system prompt... This separation keeps the stable prefix stable for caching. GitHub
• Three-tier architecture (stable / context / volatile) and separate caching layer (prompt_caching.py, provider cache breakpoints) are both real, documented components.prompt_caching.py — Applies Anthropic cache breakpoints for prefix caching Nousresearch

Minor caveats (not fluff, just unverifiable from here):

• I can't verify claims specific to the poster's own "Part 2" writeup, the "reproducible lab," or "validation receipts" — those are the poster's own artifacts, external to Hermes's official docs, and I have no way to confirm their contents or rigor.
• "Skill entered conversation history rather than the prompt snapshot" is plausible given the documented plugin/turn-context separation, but I didn't find a doc passage speaking to skills specifically in that exact framing — closest match is the general stable/volatile split.

Net: this is a well-grounded technical post. The core architectural claim (disk state updates ≠ live model context until an explicit rebuild trigger) is corroborated almost word-for-word by Hermes's own developer docs.