A large part of my career has been spent testing data rather than screens. Credit decisioning backed by financial models. MI reporting that pulled from more than twenty upstream systems. Transaction reporting and data quality validation in banks where a wrong number is a regulatory conversation. If those years taught me one thing, it's that data has a lifecycle, and the read path is the easy part to test. The defects that hurt live in the writes, the updates and the deletes: the record that was correct when it was loaded and quietly stopped being correct.

So when teams started giving agents persistent memory, my first reaction was recognition. We've seen this problem before. We just haven't noticed that we're seeing it again.

Most of the agent testing conversation, including a lot of what I've written here, is about the run: did this prompt, with these tools, produce a good answer today? Memory changes the question. An agent with memory carries state from one session to the next, and that state can be wrong in ways no single run will show you. I've started treating it the way I'd treat any production datastore. It needs tests for how it changes, monitoring for whether it's alive, and someone who owns its contents.

What changes when an agent can remember

Say your support agent learns, in a conversation in March, that refunds over a certain amount need a manager's approval. It writes that into memory, which is the whole point of giving it memory. In June the policy changes. Someone updates the policy document, and maybe a later conversation mentions the new rule.

Now the agent holds two versions of the truth. Which one does it use? Does the new fact replace the old one, or sit next to it? If a customer asks something that depends on the rule indirectly, say whether their order qualifies for a same-day refund, does the agent reason from the new rule or the old one?

Your golden set probably can't tell you. A typical eval case is self-contained: here is the context, here is the question, here is the expected answer. It tests whether the agent can find and use a fact. It doesn't plant a fact in one session, contradict it in another, and then ask a question three steps downstream. That needs a test with history, and most suites don't have any.

The life of one remembered fact: write, update, forget, retrieve, answer. Write, update and forget are highlighted as rarely tested because they need a fact planted earlier and changed later. Retrieve and answer are what golden sets and judges usually see. Underneath all five sits the memory subsystem, whose quiet failures leave every step looking fine Evals usually look at the right-hand side. Stale memory starts on the left.

Forgetting is the weak spot

The best evidence I've found for how bad this is comes from MemoryAgentBench (arXiv:2507.05257). The authors split memory into four abilities: accurate retrieval, learning at test time, long-range understanding and what they call selective forgetting, which means revising or overwriting a fact when newer information contradicts it. That last one is the refund problem.

On their single-hop forgetting task, where the agent only has to answer with the updated fact, the strongest long-context model scored 78%. On the multi-hop version, where the agent has to reason through the updated fact to reach an answer, the best result across every system they tested was 28%. Most of the dedicated memory and RAG systems scored between 2% and 7%.

They also checked that the task wasn't simply broken. On a short 6,000-token version of the multi-hop task, o4-mini scored 80%. At 32,000 tokens of history, the same model on the same kind of task dropped to 14%. So the problem is solvable when the contradiction sits close by, and falls apart once there's a realistic amount of history in between. Long history is the reason anyone builds memory in the first place.

Two charts from MemoryAgentBench. Left: selective forgetting accuracy for seven systems, single-hop versus multi-hop. GPT-5-mini with long context scores 78 single-hop and 28 multi-hop; GPT-4o 60 and 5; HippoRAG-v2 54 and 5; BM25 RAG 48 and 3; MemGPT 28 and 3; Mem0 18 and 2; Zep 7 and 3. Right: o4-mini on multi-hop scores 80% with 6K tokens of history and 14% with 32K

For a QA leader, the translation is fairly direct. If your agent can find a fact, that tells you almost nothing about whether it will act on the current version of that fact once other facts depend on it. Those are different capabilities, and on current evidence the second one is weak everywhere. I'd want a test for it before I'd trust memory with anything that matters.

One caution. FactConsolidation is a synthetic benchmark built from counterfactual fact edits. Real business facts may be easier or harder to keep straight. I don't know which, and I haven't seen anyone publish that comparison for production agents. That uncertainty is a reason to build your own probes from your own domain, not a reason to relax.

A bigger model isn't the fix

The instinct when an agent gets things wrong is to try a stronger model. AMA-Bench (arXiv:2602.22769) is a useful corrective. It tests memory on real agent trajectories, the dense mix of tool calls, state changes and machine-generated output that agents actually produce. Chat transcripts are much more forgiving.

The authors compared two levers. Scaling the backbone from an 8B to a 32B model improved average memory accuracy by about 0.04. Changing the memory architecture moved scores across a range of up to 0.45. Those two numbers aren't measured the same way, so I wouldn't turn them into a ratio, but the direction is hard to miss: on their data, how memory is built and searched matters far more than the size of the model behind it. They also found that compression and similarity search, the default design in many memory products, lose exactly the precise state information agents need later.

This matters for how a quality function spends its attention. If the team's answer to a memory defect is "we'll upgrade the model next quarter", the evidence says that probably won't fix it. The memory design is the component under test, and it deserves its own suite, its own versioning and its own change control, the same as a database schema would.

Silent failure is the part that worries me most

Benchmarks measure whether memory gives the right answer. There's a more basic question they don't ask: is the memory system even working?

A memory stack has moving parts: an embedding model, an index, hooks that write and inject memories at the right moments. Any of them can fail without raising an error. Search can quietly fall back to a weaker mode. An index can stop updating. When that happens, the agent doesn't crash. It just answers from whatever it can still reach, with the same confident tone, and your evals carry on passing because they never depended on memory in the first place.

The clearest practical account I've read is an experience report called Memory as Infrastructure (arXiv:2609.05510). The author ran a persistent memory subsystem through months of agent-assisted development and treated it like any production service: a health check at the start of every session, a heartbeat row written by every hook before it did its work, and alerting designed so that a missing heartbeat showed up as a failure. Over 78,933 recorded hook invocations there were 85 failures, and none of them were silent. 84 of those came in the first three weeks.

I'd read that carefully. It's one developer's system, and the author adjudicated some of the measures without independent review, so I wouldn't generalise the failure rate to anyone else's stack. What I take from it is the design principle: you can't count a failure you never recorded. Without the heartbeat, those 85 failures would have been 85 days of an agent quietly getting worse, and nobody would have known.

The D²ACCI paper (arXiv:2608.17756) makes a related point from the debugging side. When the authors logged each stage of the memory pipeline (ingest, retrieval, filtering, what went into the prompt), 98–100% of failures could be traced to a specific stage. With results-only logs, the figure was 0%. Same accuracy, but in one case you can fix the problem and in the other you can only see it.

Anyone who has run SRE alongside QA will recognise all of this. It's monitoring and observability, applied to a component most teams still think of as a prompt feature.

What I'd test first

I don't think anyone has a settled playbook here yet, and I'd be suspicious of anyone selling one. But if a squad asked me where to start, this is roughly what I'd say.

Write tests that have history. The basic unit is a three-part case: a session that plants a fact, a later session that changes it, and a question that depends on the change. Include at least one case where the answer depends on the updated fact indirectly, because the multi-hop results show that's where things break. Start with the entities where a stale fact costs real money or trust: prices, policies, entitlements, and anything a user has asked the agent to forget.

Make forgetting a requirement, not an accident. For each kind of fact the agent may store, someone should decide what happens on conflict. Does the newer fact win? Does it depend on the source? Should some things never be stored at all? This is a product and risk decision with a testable outcome, and it belongs with whoever owns the oracle. In most organisations that should be the quality function working with the domain owner.

Fail closed on health. If the embedder is down or the index is stale, the session should know, and a CI run against a degraded memory store should not count as green. Heartbeats are cheap. Silence is expensive.

Log the stages, not just the answer. When a memory test fails, you want to know whether the fact was never written, written wrongly, not retrieved, or retrieved and then ignored. That only works if each stage leaves a trace.

Feed production back in. When a stale-memory complaint comes in from a real user, turn it into a history-based test that week. I've written about that loop in trace-to-eval, and memory incidents are a natural fit for it.

None of this needs a research benchmark in your pipeline. A few dozen well-chosen cases from your own domain will tell you more than a leaderboard.

Who owns this

The agentic QA programme I lead now, a QA intelligence agent plus a five-agent orchestration framework on Claude, Playwright and MCP, came with an aggregate outcome of 65% fewer defect escapes and 80% fewer production incidents. I don't credit that to the models. I credit it to control points: places in the delivery flow where agent output has to meet an agreed standard before it moves on.

Memory needs the same treatment, and it raises an ownership question that most organisations haven't answered. If an agent can write durable state that changes how it behaves next month, someone has to own what it's allowed to write, how conflicts are resolved and which tests must pass before a memory change ships. Today that tends to fall between the platform team who built the memory store and the product team who use it. In my experience, things that fall between two teams don't get tested.

I'd put it with quality, because the job is the one quality has always done: deciding what correct means and proving the system still meets it after something changes.

There's a lot we don't know yet. The benchmarks are young, mostly synthetic, and they disagree on which designs work best. Very few teams have published real production data on how often agent memory goes stale. I expect the tools to get better, and some of what I've said here may look overcautious in a year. But the underlying lesson is older than any of these papers. State that persists needs tests for how it changes, not only for how it's read. We learned that with databases. I'd rather not relearn it with agents.

Continue reading

Sources