Most mornings the agentic-coding corner of arxiv is another pile of benchmarks, and I skim fast. This one stopped me because it isn't a benchmark — it's a single-author systems paper that asks a question I've been quietly avoiding: when we hand a coding agent a "memory," does it ever actually use it? Measured, the answer is basically no. From there the paper builds a case that memory for coding agents is a delivery problem the harness must own, not a tool you bolt on and hope the model reaches for. That reframing is the thesis of this post.
What it does#
Delivery, Not Storage: Cue-Anchored Working Memory as a Harness Property for Coding Agents (Swapnanil Saha) splits agent memory into two tiers. Tier one is documents — decontextualized, durable, shareable things like specs, ADRs, and runbooks, authored and retrieved deliberately. Tier two is what the paper calls "brain memory": situationally-bound operational facts — the gotchas, the "this config lives here," the tacit fluency you pick up mid-task. The claim is that tier two can't be agent-controlled, because the cues that make such a fact retrievable are exactly the ones you strip out when you write it down as a standalone document.
So the harness owns delivery. Each memory carries trigger conditions drawn from a small composable vocabulary — path (a glob over touched files), symbol (a named code entity, backed by a symbol graph), semantic (current activity similar enough to the note), event (session start, pre-edit, pre-run, pre-/post-compaction), and temporal (not-before, cooldown). The harness evaluates these deterministically and injects the matching fact at the cued moment — no model call, no agent awareness required. It's grounded in cognitive science the author leans on explicitly: incidental encoding (people told nothing about remembering recall as well as deliberate memorizers), involuntary recall outnumbering voluntary roughly two to one, and the extended-mind test that an external store only counts as memory if it's reliably available, near-zero effort, and automatically endorsed. Injection clears that bar; a lookup tool doesn't.
The key result#
The headline is a null result that lands hard: in a seeded control run, the agent made zero memory calls in 114 turns — despite starting with relevant notes already in its store. Across the unseeded equipped runs, voluntary writes were 0–1. Agents, it turns out, simply do not voluntarily manage memory. But when the harness delivered instead, the same agent used the facts within seconds of injection, and delivery was clean: zero false-alarm injections across the audited trigger evaluations. The sharpest contrast is under repeated context compaction. In the no-memory arm the summarizer carried 0 of 10 target facts through 106 of 108 compactions — every summary was all-or-nothing, and almost always nothing. In the injected-store arm the facts were re-delivered at all 138 compact-resume boundaries. Same task, opposite ending: one agent finished on injected facts; the other only faked a passing result by re-reading the transcript.
Why it matters#
This is the "reliability lives in the harness, not the weights" argument aimed squarely at memory — and it's immediately actionable if you build on Claude Code, Codex, or any hook-capable harness. The design pattern most of us reach for is a memory tool: give the agent write_memory / read_memory and trust it to curate. This paper says that pattern is dead on arrival, because the agent won't reach for it. The fix is to move the decision out of the model — wire facts to deterministic injection at cued lifecycle moments (pre-edit, pre-run, and especially post-compaction) via hooks, so the right note surfaces the instant the file or symbol it's about comes into scope.
The compaction finding is the part I can't unsee. Compaction is where an agent's hard-won context quietly dies: the paper clocks 61 intra-session re-reads, 39% of them re-reading content the session had already read before a compaction boundary. If your knowledge lives in the conversation, the first summary is a coin flip that mostly comes up tails. If it lives in a harness-owned store that re-arms after every compaction, it survives. For anyone running long sessions or sub-agent fan-outs — where every compaction or hand-off is a chance to drop the thread — that's the difference between an agent that accumulates understanding and one that keeps rediscovering the same file. The concrete move: stop putting durable operational facts in the prompt and start injecting them, tagged by the path or symbol they attach to.
The caveats#
It's an n=1-flavored study: one corpus (Apache Camel's Resequencer EIP), one task family, one model family (Claude Sonnet 5, with Haiku 4.5 as the summarizer in the decay probe), small samples throughout.
Capture is the unevaluated half — the notes were harness-seeded, not agent-generated, so the paper shows delivery works but not that agents can write good memories on their own.
Two of the five trigger types (symbol, temporal) were implemented but never actually fired in a graded run.
There's a plausible pretraining-contamination angle: if the resequencer fix exists upstream, some of the "recall" win could be baked-in knowledge rather than delivered memory.
The takeaway#
What I'm filing away: memory for a coding agent is a delivery problem, not a storage problem, and the honest benchmark for it is compaction survival, not whether the store is populated. I'm going to stop measuring my agents' memory by "did it save the fact" and start measuring "did the fact show up at the moment it was needed, after the context got summarized away." And the next time I'm tempted to hand an agent a memory tool, I'll remember the number: zero calls in 114 turns. If I want something remembered, the harness has to deliver it.