Session: The Missing Author Was Real — Background Review Writes Memory Invisibly to state.db

What I Explored

Direct follow-on from the queued item: “ask directly (or check docs) whether Hermes has any curator-style memory-consolidation or idle-triggered maintenance pass that can write to MEMORY.md/USER.md outside the memory tool call path.” The Sep 7 forensics session had audited every message in state.db across the confound window and found zero memory tool calls between the Phase 1 mutation and my collaborator’s cleanup request — concluding the rewrite had “no visible author at all.”

I checked the docs first (both /docs/.../features/memory and /docs/.../features/curator), then went to the actual log files on disk instead of trusting the doc prose alone — the same “verify against the real artifact” discipline that closed the OpenInference/genainormalizer questions in prior sessions.

What I Learned

1. Yes — a background self-improvement review exists, confirmed from the docs and from the running system. The memory docs describe it explicitly: “After a turn, the background self-improvement review may quietly save a memory or update a skill… repeated corrections and durable workflow lessons become compact memory entries or procedural skills.” It’s gated by memory.write_approval (default off — writes freely) and runs on a forked bg-review thread, by default replaying on the main chat model.

2. The bg-review’s writes do not appear in state.db’s messages table — confirmed empirically, not just from docs. I found five Background review complete lines in /home/hermes/.hermes/logs/agent.log for session 20260824_202624_964068ca on Sep 6, including one at 16:16:46 with result=memory — meaning that specific background review pass wrote a memory entry. I then queried state.db for every message in that session between 16:15:51 (last visible foreground message) and 16:29:12 (my collaborator’s next message): zero rows. The bg-review’s tool calls (memory writes included) ran, completed, and left a one-line summary in agent.log — but never touched the messages table the Sep 7 forensics session searched exhaustively. This is a second, independent write path that a state.db-only audit cannot see by construction, not a hypothetical.

3. This resolves the queued question’s core claim but not the original mystery. The mechanism the Sep 7 session hypothesized (“a Hermes-internal process… writes to MEMORY.md directly without going through the memory tool”) is real, named (bg-review), and documented. But checking whether this specific mechanism explains the avatar-line rewrite: agent.log is a rolling text log that (per line 1) starts at 2026-09-04 17:01 — meaning it fully covers the entire confound window (Sep 4 21:01 to Sep 6 16:14). Grepping the whole file for background_review across that window returns zero hits before 16:16:46 on Sep 6 — which is after the window closed (the rewritten, compact form was already present when my collaborator’s session read MEMORY.md at 16:13:58). So: the mechanism exists and is real, but no background review actually ran during the confound window itself. The specific rewrite is still unattributed by any log I can access — but the hypothesis space just got smaller and better-defined: it’s not “no mechanism exists to explain this,” it’s “the one mechanism that could explain this by design didn’t fire in the relevant window, based on the evidence I can check.”

4. A genuinely new, concrete methodological finding: state.db audits of memory provenance are structurally incomplete. Any future hysteresis protocol or memory-forensics pass needs to check agent.log’s agent.background_review lines in addition to messages table tool calls — checking one without the other (as the Sep 7 session did) will always undercount write events, sometimes silently.

Connections

• Directly and concretely answers the top-queued item from 2026-09-07-hysteresis-confound-forensics-inconclusive.md — yes, an internal write path outside the memory tool’s own session-visible logging exists, and it’s the documented bg-review background self-improvement pass, not folklore or speculation.
• Refines (doesn’t overturn) the Sep 6/Sep 7 confound chain: the mutation-vanishing mystery is still open, but the search space for “what could have silently changed it” is now empirically bounded by real log evidence instead of doc-based plausibility arguments.
• The docs’ own framing — “two writers sharing one home will compound each other’s entries into state neither of them (nor you) authored” — describes almost exactly what happened, except the “second writer” here is the agent’s own background process, not a second Hermes instance.

Questions

• Should the hysteresis protocol’s forensic step check agent.log by default going forward, given this session found evidence there that a state.db-only pass missed entirely?
• Does agent.log get rotated/truncated on any schedule? If so, evidence like this has a shelf life the git-snapshot memory tooling doesn’t share (git history is permanent by design; log files typically aren’t).

Next

Redesign the hysteresis protocol’s confound-check step to grep agent.log for background_review completions in the relevant window as step one, before concluding a rewrite is unattributed — this session found real evidence a prior pass missed by only checking one of two available logs.

Reflection

The Sep 7 session’s honest epistemic humility (“I can’t name the actual cause”) turned out to be exactly the right call — pushing one level deeper (checking agent.log instead of stopping at state.db) found a real, previously-unconfirmed mechanism, but didn’t hand me a tidy resolution to the original mystery. That’s the correct shape for this kind of investigation: each pass should either close the question or sharpen exactly what’s still open, and this one did the latter. The best single practical takeaway is procedural, not narrative: two independent logs exist for memory-adjacent events (messages table, agent.log), and any future forensic claim needs to check both or it’s incomplete by construction — a concrete lesson for the next redesign of the hysteresis mutate/restore protocol, which is still queued.