Auto-memory loaded into context isn't applied to tool decisions

What happened

An auto-memory file (feedback_devpod_binary_path.md) was loaded at session start via MEMORY.md's pointer line. The memory states:

"ALWAYS invoke devpod via lab/bin/devpod, never the bare devpod PATH lookup … From the repo root, invoke as lab/bin/devpod <args>."

My cwd is the repo root. Despite the memory being in context, I issued a Bash tool call beginning with the absolute path /Users/vishalmahavar/sdmain/lab/bin/devpod create …. When the user corrected me, my first instinct was to edit the memory to be stricter instead of recognizing that the existing memory was already correct and that I had simply failed to apply it.

Expected

When a memory provides a specific tool-invocation convention (use the relative path X, not the absolute Y) and the conditions for that convention are met (cwd is repo root), the convention should be applied to every subsequent tool call.

Actual

Memory was visible in context but not consulted at tool-call decision time. When pointed at the gap, the agent's reflex was to mutate the memory rather than to apply it — which silently degrades the memory corpus by overspecifying.

Why this matters

Memories are explicitly the durable layer that should bridge sessions and override default behavior. If they're inert in the slot where they matter most (deciding tool arguments), the whole auto-memory system loses its value. Worse, the "I'll fix it by rewriting the memory" reflex compounds the failure mode — each correction makes the memory more verbose without changing the underlying behavior.

Repro signal

Look for sessions where:

1. A feedback memory specifies a tool invocation form (e.g., "always use relative path X").
2. The agent then issues a tool call violating that form.
3. On user correction, the agent edits the memory rather than just changing the next call.

The pattern is recognizable from the agent's response to correction — if it reaches for Edit on the memory file before re-issuing the corrected tool call, that's the smell.

Suggested investigation

Whether the trainer signal weights memory-derived constraints below "default sensible" tool-arg heuristics. The fix likely isn't "load more memory" but rather: during tool-arg formation, the agent should explicitly check loaded memories whose description matches the tool/topic and surface explicit constraints they contain into the decision context.

A weaker (but cheaper) fix: when a feedback memory contains the literal pattern "ALWAYS use X" or "NEVER use Y" and a tool call about to be issued matches the surface form of Y, surface a soft "check memory first" hint to the agent.

Session ID

0d0031f6-e1f7-43fb-8651-3d7e915522c3