Your AI Agent Doesn't Have a Memory. It Has a Context Window -- And That Is the Problem

Synergised Consulting Ltd

30 October 20269 min read

Last Updated: 30 October 2026

An AI agent does not have a memory; it has a context window that gets refilled, and a persistent store of notes that get replayed into it. Both fail quietly. What an owner should decide is what the agent stores, what it expires, and how that store is tested -- because unmanaged memory degrades answers and can be poisoned, and neither failure looks like a failure from the outside.

What an Agent's "Memory" Actually Is

An agent's memory is two different mechanisms that owners often hear described as one thing. The context window is the text the model reads on this particular request: the task, your instructions, and whatever history or notes the agent's software decides to attach. It has a finite size, and once a request is answered, none of it persists by itself. Persistent memory is a separate store -- files, database rows, retrieved summaries -- that the agent writes during one session and its software re-attaches in later ones.

Neither mechanism behaves the way human memory does, and neither is reliable by default. The context window is not a faithful recorder: research shows model performance changes depending on how much text is in it and how that text is arranged. The persistent store is not a curated knowledge base: whatever got written there gets treated later as trusted prior knowledge, whoever wrote it and however it got there. Both facts are measurable, and both have been measured -- which is what the next two sections cover.

What the Evidence Says About Long Context

The clearest published evidence that a bigger context is not a better memory is Chroma Research's context rot study. According to Chroma Research ^[1], performance consistently degraded as input length grew across every one of the 18 models tested -- including frontier models from OpenAI, Anthropic, Google and Alibaba's Qwen team -- even on tasks as simple as retrieving a fact or repeating a sequence of words. The study held task difficulty constant and varied only the input, so the degradation is attributable to length and clutter rather than harder questions.

Three details from the study matter more for a business owner than the headline. First, a single distractor -- one irrelevant but topically similar item in the context -- measurably reduced performance, and four distractors compounded the damage. Second, on LongMemEval, a benchmark built from realistic chat histories over 100,000 tokens, models performed better when given only the relevant sections of the conversation than when given the full history ^[1]: the focused extract beat the complete record. Third, the model families failed differently under ambiguity -- Anthropic's Claude models tended to abstain, while OpenAI's models tended to give wrong answers that sounded plausible ^[1]. A plausible wrong answer is the more dangerous failure in a business setting, because nobody sees it happen.

There is also a counterintuitive structural finding: shuffling the surrounding text -- destroying its logical flow -- improved retrieval performance on all 18 models ^[1]. How information is arranged in context matters as much as whether it is present. That is the study's own conclusion: whether relevant information is present matters less than how it is presented, which is why the authors call for deliberate context engineering rather than bigger windows.

What the Evidence Says About Poisoned Memory

Degradation is the passive failure. The active one is poisoning: adversarial content that enters an agent's persistent memory through ordinary operation and is later retrieved as trusted knowledge. Because the poisoned entry is inside the store rather than in this request's input, the payload does not need to be present again -- one successful write is enough to influence future sessions, according to a systematic study of memory poisoning in LLM agents published on arXiv in June 2026 ^[2].

That study put numbers on how exploitable this is. Across the two agent architectures it tested, attacks averaged a 50.46% success rate at getting a malicious write stored and a 41.05% rate at getting it retrieved and acted on later; on one architecture, strong-signal attacks achieved retrieval rates as high as 92.76% ^[2]. It also found that agents designed to read and write memory more aggressively were more exploitable, and that existing prompt-injection defences provided incomplete coverage of memory attacks specifically ^[2].

Subsequent work in 2026 confirmed the pattern against production harnesses rather than laboratory setups. A persistent memory poisoning attack (PMPA) evaluated against OpenClaw and Claude Code achieved average injection and cross-session attack success rates of 73.7% and 55.5% on OpenClaw, and 66.9% and 81.7% on Claude Code, while leaving benign task performance intact -- so the owner sees the agent working normally ^[3]. A separate attack, GhostWriter, achieved injection rates of approximately 98% and activation rates of approximately 60% against state-of-the-art personal agents, with its authors attributing the exposure to the lack of security-focused memory governance in current memory subsystems ^[4].

What Fixing It Actually Means

One more finding deserves an owner's attention because it changes what "fix it" means. The PMPA researchers tested a targeted prompt-level defence and found it reduced memory injection in many settings, but provided limited protection once the persistent memory had already been poisoned ^[3]. A poisoned store is not patched; it has to be cleaned. That is why the decisions below are made before an incident, not after one.

What to Store, What to Expire, What Never to Store

Store facts with provenance, not raw transcripts

The useful distinction is between what the agent observed and what is actually true of the business. A raw transcript replay treats everything the agent has ever read -- including emails, web pages and documents from outside the business -- as equally trustworthy background. The memory poisoning studies show exactly that pathway: untrusted external content gets written during a benign task and retrieved later as if the business itself had vouched for it ^[2]. Storing an item with a note of where it came from, and who confirmed it, is what makes a later retrieval auditable.

Expire on a written rule, not on a feeling

Old instructions and stale facts do not announce themselves; they sit in the store and get retrieved as if current. The fix is an expiry rule written down before deployment: price lists and policy statements expire when superseded, project-specific notes expire when the project closes, and anything not confirmed within a set period drops out of retrieval entirely. The rule matters more than its specifics, because a written rule gives the person accountable something to check, and it turns "why did the agent do that?" from an archaeology exercise into a lookup.

Never store anything you would not write on a whiteboard

Two categories fail this test. The first is credentials and anything credential-shaped -- the poisoning studies show stored content steering an agent towards attacker-controlled endpoints ^[2], and a secret in the store is a secret one retrieval away from an attacker's context. The second is unverified opinions about people: customer sentiment, staff performance judgements, anything that would be contentious if read aloud. These get stored because an agent summarising its day has no judgement about what should persist. The person accountable decides the categories, and the agent's memory policy enforces them.

Give memory writes the same scrutiny as spends

An agent that can spend money usually has an approval threshold; an agent that can write to its own long-term memory usually has none. The GhostWriter authors' proposed mitigation, Agentic Memory Sentry, combines a memory-saving policy with a screen applied at retrieval time, and their experiments show it reduces attack success while preserving the agent's utility ^[4]. The operating version of that idea is simpler: require the same class of decision -- what deserves to persist, and what gets filtered out at retrieval -- to have a named owner and a documented rule, just as spend approvals do.

How to Test That Memory Is Not Lying to You

A memory policy that is never tested is a document, not a control. The test is deliberately low-tech: write down a fixed set of ten to twenty questions the business actually asks its agent, capture the agent's answers while its memory is in a known state, and re-run the same set after any change to what the agent has stored, what it has read, or how its context is assembled. If an answer drifts -- a price changes, a policy reverses, a name is wrong -- the drift is in the memory or the context, and now it has a date and a before-and-after.

Two properties make this worth doing. It is cheap: the evaluation set is an afternoon's work, and re-running it is minutes. And it catches the passive failure the studies describe, not just the dramatic one. An agent whose context has accreted months of half-relevant notes will not refuse to answer; it will answer slightly worse, occasionally, on questions nobody is checking ^[1]. A fixed question set is exactly the checking nobody was doing.

What Testing Cannot Fix

What testing cannot do is repair an already-poisoned store -- the PMPA study found prompt-level defences provide limited protection once poisoning has happened ^[3]. So the test run pairs with a clean-state discipline: when answers drift and no benign explanation shows up in the store's recent writes, restore the memory to its last known-good state rather than trying to argue the agent out of what it remembers.

What an Owner Should Take From This

In discovery workshops, owners rarely arrive with a list of what their agent should remember. The list gets built in conversation, walking through a normal week task by task -- and the same is true of memory: what is worth persisting only becomes visible when someone walks through what the agent actually did last week and asks which of it should still be true next month. That conversation, plus a written expiry rule and a fixed question set, is the whole governance layer this research points at. None of it requires a bigger model. All of it requires someone willing to be the person who decides.