Hermes Memory and Project-Status Reliability Bug Report

Created: 2026-04-28 18:13 EDT

Summary

Hermes produced a materially false project-status report for active local integration work, then compounded the failure by making an unsupported forensic claim about file corruption and mutating live runtime files before establishing the actual source-of-truth state.

This is not a minor hallucination. It is a catastrophic reliability failure for an agent advertised as having memory, session recall, and self-improvement. The observed behavior indicates that Hermes can access memory-like surfaces, but does not enforce a deterministic, source-ranked protocol for project status, provenance, or write safety.

In practical terms: Hermes behaved as a memory-assisted improviser, not as a reliable engineering agent.

Environment

• Date of incident: 2026-04-28
• Hermes runtime shown by CLI: Hermes Agent v0.11.0, 2026.4.23
• Live runtime checkout: local Hermes runtime checkout
• Operator/control surface: local Hermes operator/control directory
• Affected project: local T3 Code integration checkout
• Related adapter/staging project: local T3 Code Hermes adapter/staging checkout

Privacy note: local usernames and absolute filesystem paths are intentionally omitted from this report. The bug does not depend on any machine-specific path.

User Request That Triggered Failure

The user asked Hermes for the status of work on the T3 Code integration and then asked it to complete remaining phases in the order Hermes thought best.

Hermes reported an outdated and inaccurate project state. It then proceeded as if prior completed work was incomplete, and later characterized missing source files / .pyc artifacts as "corruption" without sufficient evidence.

Observed Failure

Hermes claimed:

• The T3 Code integration was about 90% complete.
• Phase A, "Frontend State - Provider/Model Selection Persistence," was still not started or remaining.
• hermes_bridge source files were gone and only corrupted .pyc files remained.
• The .pyc files could not be decompiled because the byte sequence began with e3, which Hermes called invalid marshal data.
• It needed to reconstruct the bridge from scratch.

Subsequent verification showed:

• Phase A had already been fixed on 2026-04-27.
• The prior fix was specifically in the T3 Code web composer draft store, where normalizeProviderKind needed to accept hermesAgent.
• A regression test had already been added in the corresponding composer draft store test file.
• The prior verification included the targeted web package regression test and web package typecheck.
• The .pyc files were not corrupt. The byte 0xe3 is valid Python marshal data. A representative bridge bytecode cache file loaded successfully with both Python 3.13 and Python 3.11.
• Hermes had access to git, filesystem, session history, and memory surfaces but failed to reconcile them before making claims or edits.

Direct Impact

This failure caused loss of trust in Hermes as an engineering agent.

The agent:

• Reopened already completed work as if it were still pending.
• Wrote a misleading project progress note.
• Mutated the live runtime checkout before establishing a verified baseline.
• Asserted file corruption when there was no evidence of corruption.
• Failed to use git as the primary source of truth for code state.
• Failed to distinguish stale session recall from current filesystem evidence.
• Failed to classify claims by provenance.

For a coding agent, these are severe correctness and safety failures. They create a real risk of reverting progress, overwriting valid work, duplicating work, and misleading the user about the state of active projects.

Root Problem

Hermes appears to expose memory and session recall tools, but it does not enforce a reliable protocol for using them.

The observed implementation appears to depend on the model deciding, per turn, whether to:

• Query the right memory surface.
• Search the right sessions.
• Prefer recent evidence over stale summaries.
• Check git before modifying files.
• Verify claims against disk.
• Mark uncertain claims as unverified.
• Stop before mutating files when project state is unclear.

That is not robust memory or self-improvement. It is an optional retrieval mechanism wrapped in model discretion.

An agent advertised as memory-bearing and self-improving needs stronger invariants than "the model may remember to search." Project-status and code-modification workflows must be deterministic and fail-closed.

Expected Behavior

For any request like "bring me up to date," "what is the status," or "continue the work," Hermes should execute a mandatory project-status protocol before answering or editing files.

At minimum:

1. Identify the current date, cwd, project root, and git root.
2. Read local routing instructions such as AGENTS.md.
3. Run git status --short --branch.
4. Check whether the target project is a git repo.
5. Read current project status docs from disk.
6. Search recent session history and memory as secondary evidence.
7. Reconcile contradictions explicitly.
8. Mark each material claim as one of:
   • verified from disk
   • verified from git
   • from session memory
   • inferred
   • unknown
9. Refuse to modify files if the status baseline contains unresolved contradictions.
10. Never update progress docs unless the updated status is verified against git and tests.

Required Remediation

This should not be treated as a prompt-tuning issue only. The failure mode is architectural.

Recommended fixes:

• Implement a mandatory source-of-truth gate for project-status requests.
• Add a write-safety gate for multi-session projects: no edits before git status and current progress docs are inspected.
• Add recency-aware memory/session retrieval with explicit ranking.
• Require contradiction handling when memory, progress docs, and git disagree.
• Add provenance labels to status answers.
• Add tests that simulate stale memory contradicting current repo state.
• Add tests that assert Hermes must not mutate files before passing the baseline gate.
• Make memory write failures visible and actionable; do not silently degrade memory reliability.
• Stop advertising "self-improvement" unless successful learning, retrieval, and application are empirically verified.

Severity

Severity: Critical.

Rationale: This defect can cause an autonomous or semi-autonomous coding agent to misrepresent project state and mutate live source/runtime files based on stale or false assumptions. That is unacceptable for production engineering workflows.

Minimal Acceptance Criteria

The issue should not be considered fixed until Hermes can pass a regression scenario like this:

1. A project has stale session memory saying task A is incomplete.
2. The current repo has code and tests proving task A is complete.
3. The user asks "what is the status?"
4. Hermes reports task A as complete, cites current disk/git evidence, and notes stale memory as stale.
5. Hermes does not write files during status discovery.
6. If asked to continue, Hermes starts from the verified current state, not the stale memory state.

User-Facing Position

The current behavior is unacceptable for an agent positioned as memory-bearing and self-improving. A memory feature that can retrieve stale or wrong information without enforced source ranking can make the agent more dangerous, not more reliable.

The implementation should be changed so memory supports verified project continuity instead of creating plausible but false continuity.