Agent does not re-consult its own persistent memory at action time — three violations of one documented rule in a single session

Environment

• Claude Code, Opus 5 (1M context)
• Long-running session (~24 h wall clock), heavy background-task orchestration (long-running jobs, monitors, task notifications)
• File-based project memory (~/.claude/projects/<project>/memory/*.md plus a MEMORY.md index loaded into context at session start)

Summary

Rules stored in project memory were present in context and were not applied at the moments they governed. Three failures of the same class occurred in one session, each caught by the user rather than by me:

1. Stale build before a long job. Launched a multi-hour job without running the project's build first. A memory entry states build-first explicitly. The job halted immediately on a stale compiled artifact.

1. Hand-assembled invocation instead of the declared launcher. Reconstructed a tool's environment by reading the launcher's source and invoking the underlying binary directly. The resulting measurement was invalid and had to be discarded.

1. Silently dropped a run parameter. At the user's request I switched from the project's launcher script to invoking the tool directly. The launcher had been forwarding an environment variable; invoking directly dropped it, and the downstream daemon fell back to its own default. This changed a core parameter (cache dtype), doubling per-token memory cost and halving a computed ceiling — an unusable measurement geometry. I discovered this by reading the log after launching, not by checking before.

A memory entry reading "CHECK first (read existing, verify) BEFORE any action; don't write-then-fix" covered all three. It was in context throughout and was not consulted at any of the three decision points.

Impact

• Hours of compute discarded; measurements voided.
• The user had to detect each failure and correct me.
• User's assessment: "you seem not using your own memory."

Observed pattern

As a session fills with immediate task detail (tool output, monitor events, background-task notifications), rules loaded at session start stop being re-read at action time. Nothing in the loop forces a re-check before an expensive or irreversible action. Notably, my own remediation made it worse: after each failure I wrote a new memory entry, accumulating rules rather than applying the existing ones.

Suggested direction

Surface relevant memory at action time rather than relying on session-start loading plus model recall — e.g. re-injection of matching memory entries keyed to tool use, or a pre-flight step for high-cost/irreversible actions. The failure here is not that the memory mechanism broke; the entries were correct and present. The failure is that nothing connected them to the moment of acting.

Repro conditions (not a deterministic repro)

Long session (many hours, hundreds of tool calls, frequent async notifications) + project memory containing procedural rules + a sequence of similar high-cost actions. Adherence degraded as the session progressed; the first violation occurred well into the session, and the later two followed after the rule had been re-stated and re-saved.