First surfaced in Tandemly Briefing — 2026-08-31.
Your cached memory
has no expiry.
Every time an agent carries knowledge from one session into the next, it takes a quiet gamble: is that information still true? Servers change. APIs add fields. Schemas shift. The agent has no mechanism to find out except by trying and failing. Wu and Canedo argue this is a protocol problem, not a storage problem, and propose a fix that belongs on the wire.
Stale discovery
is not the same as
stale avoidance.
The agent memory literature has been asking "how do agents find the right memory?" This paper asks a different question: how does the server tell the client when its memory went wrong?
Agent systems increasingly cache information across sessions. When you ask an agent to help you next week with the same service it helped you configure last week, it should be able to draw on what it learned. The field has spent considerable effort making that retrieval better: denser indexes, smarter similarity metrics, tiered storage architectures.
Those investments all share the same blind spot. They help an agent find a cached entry. None of them tell the agent whether that entry is still true. The underlying service may have changed its API, added a required field, or moved a configuration parameter since the last session. The agent discovers this by trying the cached suggestion and watching it fail. That is stale discovery: learning about staleness through failure.
What the field has not addressed is stale avoidance: the client knowing, before it tries, that a cached item is no longer valid. For that to work, the server needs a way to say so. No standard protocol for agent memory provides one.
The existing memory literature treats this as a client problem: build a better retriever, compress the cache more intelligently, add a reranker. Wu and Canedo treat it as a protocol problem: put the validity signal on the wire so the client does not have to guess. The server owns the truth about whether its own outputs are still valid. It should say so.
Version stamps,
cacheability hints,
and a clean decomposition.
The proposed invalidation contract attaches version stamps and cacheability hints to every recovery suggestion. When the underlying data changes, the server signals exactly which cached entries are stale and at what granularity.
The mechanism is straightforward. Every suggestion the server sends carries a version stamp tied to the relevant data state, plus a cacheability hint saying how long and at what granularity the suggestion should be trusted. When that state changes, the server issues an invalidation that the client can match against its cache and evict deterministically, rather than waiting to discover the staleness through a failed retry.
The insight that makes this design tractable is a decomposition. Total cache savings do not depend on one variable; they depend on two independent ones. Validity is the fraction of cached suggestions that are still correct after a drift event. It is a protocol property: the design of the contract and the granularity of the invalidation signal determine it, independent of which model is running. Compliance is the fraction of valid invalidation signals the planning model actually applies on the first try. It is a model property: the protocol can be perfect and compliance can still be low.
That decomposition is the paper's most transferable contribution. It tells you which half of the problem to fix. Low validity means improve the protocol. Low compliance means examine the model.
The evaluation ran across seven models, three serving paths, two domains, and approximately 9,400 episodes. Granularity was varied between row-level and table-level to isolate the granularity effect cleanly. The domains were narrow: API error recovery scenarios. Generalization to other memory content types is not yet tested.
Granularity is binary.
Compliance is a
model property.
Two findings reshape how teams should think about cross-episode memory. The first is about granularity. The second is about which model they pick.
Claude Haiku 4.5
Claude Sonnet 5
zero contract failures
Row-level invalidation raised first-try compliance from near zero to 55.6-66.7 percentage points on three models, and recovered 29-33% of baseline token cost on four of seven models. Eviction precision hit 1.00 at row granularity on every model under the paper's row-level oracle.
Table-level invalidation produced a different outcome entirely. Invalidating at the table level destroys co-located entries, not just the stale one. First-try compliance dropped to 0% on five of seven models after a drift event. This is not degraded recovery. It is no recovery. The granularity choice is binary: row-level is survivable, table-level is not.
The most consequential number in the paper is the compliance gap between Claude Haiku 4.5 (100%) and Claude Sonnet 5 (11% or below). The failure mode on Sonnet 5 was specific: input-schema conservatism. Sonnet 5 refused to apply fixes that added fields not present in the original request, even when the invalidation contract supplied a valid signal authorizing that change.
The implication is direct. A stronger model is not a safe substitution for a model that already works. For deployments that depend on cross-episode cache reuse, compliance is a first-class selection criterion alongside capability. Measure it before committing to a model choice.
Results are based on a row-level oracle defined in the paper. The evaluation domains were narrow (API error recovery). Generalization to other memory content types, such as conversational history or multi-turn task state, is untested. The overhead figure of 15% added response payload is honest and consistently reported across conditions; no contract failures were observed in the evaluation.
What to do
with this.
The invalidation-contracts pattern applies to any agent system that caches server-side suggestions across episodes. The compliance finding applies to any system that depends on a planner model acting on a structured signal.
Where to go
from here.
Concrete next steps if you want to apply or extend this work.