When to Remember: A Preregistered Study of Failure-Memory Delivery Timing in an LLM Coding Agent

Abstract

Research on memory for LLM agents has concentrated on what to remember: what to store, how to consolidate it, and what to retrieve. This paper offers preregistered evidence that for failure memories, when and where the memory is delivered can matter more than what it says. On synthetic TypeScript repair tasks built around trap fixes, an open-weight coding model frequently repeated its own previously observed failure. A matched memory of that failure injected at turn start, the delivery point used by current memory systems, failed its registered support test and showed a worse task-pass estimate than an equivalent success memory. The identical fact evaluated against the agent's proposed action, as a just-in-time advisory, eliminated repetition of the known failure: a 35.6-percentage-point reduction (p = 0.0019), confirmatory on all 18 preregistered tasks with zero invalid rows and zero protocol deviations. Prevention did not become completion (+1.5 pp, interval touching zero): the mechanism removes a known failure mode rather than improving the agent overall. The design implication is architectural. Failure memories should be routed to the action site as advisory guardrails, not inserted into the prompt preamble. Our first registration returned NOT_ESTIMABLE under its own zero-cut rule; we report both registrations in full. The task corpus, harness, registrations, episode logs, and analysis artifacts are public and replay byte-for-byte. Task dataset: https://huggingface.co/datasets/joshuaswarren/h6-failure-gate-tasks Harness, registrations, and run artifacts: https://github.com/joshuaswarren/remnic/releases/tag/h6-study-2026-08