What is AI agent memory, in practical terms?

It's a persistent store the agent writes facts into and reads back on later runs, separate from the model and separate from your systems of record. Practically, it's a second copy of your operational data — customer preferences, account states, decisions, things somebody said once in a thread — held outside the database that owns those facts. That's the part teams miss. Memory is usually procured as a model feature, so it inherits none of the disciplines storage gets: no schema review, no retention rule, no access log, no owner on the org chart, and no reconciliation against the system that actually owns the fact.

Can AI agent memory be poisoned, and does the poison persist?

Yes, and persistence is the whole point of the attack. In a preprint submitted 6 July 2026 (arXiv 2607.05189, Zhang et al.), researchers introduced WhisperBench — 108 test cases across five risk categories — and an attack framework called MemGhost. A single piece of untrusted external content, delivered as an ordinary email, gets written into the agent's persistent memory and reloaded as trusted state in later sessions. Reported success rates were 87.5% against OpenClaw running GPT-5.4 and 71.4% against the Claude Code SDK agent on Sonnet 4.6. The distinction that matters operationally: a prompt injection ends when the session ends, but a memory injection is a write. It survives the session, and every later run reads it as something the agent already knows.

Does agent memory get worse as it accumulates?

On the available numbers, yes — and the clearest evidence comes from a vendor grading its own product. Mem0's State of AI Agent Memory 2026 report, first published 18 July 2026 and updated since, scores its retrieval on the BEAM benchmark at 64.1 with 1M tokens of history and 48.6 at 10M tokens. That's roughly fifteen points lost as history grows tenfold, in the best case its own engineering team could produce and publish. Treat it as a vendor benchmark, not an industry measure. It still points somewhere useful: accumulation is not free, and a memory store that only ever grows is trending toward its own worst score.

What happens to agent memory when the platform is retired?

Usually nothing good, and the OpenAI Assistants API is the worked example. OpenAI notified developers of the deprecation on 26 August 2025 and shuts the API down on 26 August 2026 — a full year of notice. Its migration guide states plainly: "We will not provide an automated tool for migrating Threads to Conversations." A year of warning and no automated path for the state, because Threads were shipped as a convenience feature rather than as a system of record. Anything a team has accumulated in there for a year is theirs to move by hand. Note that this is OpenAI's platform specifically — Microsoft has said Azure OpenAI is not affected by this deprecation.

How should we govern AI agent memory in an enterprise deployment?

Treat it as storage you own, not a feature you enabled. Four things, in order. First, put a name on it — one person accountable for what's in the store, the same way someone owns the CRM. Second, write a retention rule before the first write, with a default expiry, because a store with no TTL is a cache nobody invalidates. Third, decide what memory is allowed to hold: preferences and context, yes; authoritative facts like credit limits, entitlements, prices or account status, no — those get read from the system of record at use time, so memory can't hold a stale copy that outvotes the truth. Fourth, log writes with their provenance, so when a belief turns out to be wrong you can answer where it came from and what else it touched. If you can't answer "what does this agent currently believe, and who told it that," you don't have memory governance.

AI agent memory is a second database nobody wrote a retention policy for

Two things happened this summer that don’t fit together. Agent sessions can now run for fourteen days, and one of the most widely used stores of agent conversation state gets switched off in twelve. AI agent memory arrived as a product category before anyone wrote down the boring parts — who owns the store, what expires, what gets reconciled against the system that actually owns the fact. The industry shipped persistence and skipped invalidation.

TL;DR: Agent memory is a second copy of your operational data, held outside the systems of record, with no owner, no retention rule and no reconciliation. Three 2026 measurements show the cost: a memory-injection attack succeeded 87.5% of the time against one popular agent and persisted across sessions (arXiv 2607.05189, 6 July 2026); a memory vendor’s own benchmark drops from 64.1 to 48.6 as history grows from 1M to 10M tokens; and OpenAI, after a full year of deprecation notice, says it will not provide an automated tool for migrating Threads out of the Assistants API before it shuts down on 26 August 2026. The question stopped being what your agent can do. It’s what your agent still believes, and whether that’s still true.

Persistence got a roadmap. Invalidation didn’t.

The capability side moved fast. On 6 August 2026, AWS made Bedrock AgentCore runtime instances generally available, and the wording in the announcement is the part worth keeping: runtime instances support long-running agent sessions of up to 14 days, against a default serverless microVM runtime designed for sessions of up to 8 hours. That’s a forty-two-fold increase in how long a single agent’s working state can sit there, accumulating.

Nothing shipped alongside it that says when any of that state stops being true.

That’s the asymmetry. Every vendor roadmap has a memory feature. I have yet to see one with an expiry policy, a reconciliation job, or a field-level statement of which system wins when the memory and the database disagree. Those aren’t exotic asks. They’re the standard furniture of any data store built in the last thirty years, and they’re missing here because memory was sold as a model capability rather than as storage. Nobody puts a retention schedule on a feature.

So you end up with an agent that has been running for two weeks, holding a few hundred facts it picked up along the way, none of which have a timestamp anyone checks against the source. A customer’s credit limit changed on Tuesday. The agent learned it on Monday.

Three measurements from this summer

What was measured	Finding	Source
Stealth memory injection via one email	87.5% success on OpenClaw / GPT-5.4	arXiv 2607.05189, submitted 6 Jul 2026
Same attack, different agent	71.4% success on Claude Code SDK / Sonnet 4.6	arXiv 2607.05189, 6 Jul 2026
Benchmark scope	WhisperBench: 108 test cases, five risk categories	arXiv 2607.05189, 6 Jul 2026
Retrieval quality at 1M tokens of history	64.1	Mem0 State of AI Agent Memory 2026
Retrieval quality at 10M tokens of history	48.6	Mem0 State of AI Agent Memory 2026
Max agent session length, new AWS runtime	14 days (vs 8 hours default)	AWS, 6 Aug 2026
Automated migration path for Assistants Threads	None provided	OpenAI migration guide
Assistants API shutdown	26 August 2026, announced 26 August 2025	OpenAI deprecations

The write survives the session

The security finding is the one I’d bring to a risk committee. In a preprint submitted 6 July 2026, Yechao Zhang and colleagues describe MemGhost, an attack that plants a false belief in a persistent personal agent’s memory using a single piece of untrusted external content — an ordinary email. It reported 87.5% success against OpenClaw running GPT-5.4 and 71.4% against the Claude Code SDK agent on Sonnet 4.6, measured over a 108-case benchmark the authors call WhisperBench.

Prompt injection is a conversation you can end. This is a write.

That’s the whole difference, and it’s why the mitigations most teams have built don’t apply. Input filtering, session isolation, per-run sandboxes — all of it is scoped to a session, and the payload’s entire purpose is to outlive the session. It goes in once and loads as trusted state every time after. You can hand the agent a clean context window on Thursday and it will still believe the thing it read on Monday, because it isn’t reading it any more. It’s remembering it.

Accumulation isn’t free

The second number comes with a caveat I want to state before the number itself: it’s a vendor scoring its own product. Mem0’s State of AI Agent Memory 2026, first published 18 July 2026 and updated since, reports its retrieval scoring 64.1 on the BEAM benchmark at 1M tokens of history and 48.6 at 10M tokens. On the two benchmarks where the histories are shorter — LoCoMo at 1,540 questions, LongMemEval at 500 — it scores 92.5 and 94.4.

Read it as marketing and it’s still useful, because of the direction. This is the number the vendor chose to publish, from the best configuration its engineering team could build, and it loses about fifteen points as history grows tenfold. Nobody publishes their unflattering curve unless the flattering one doesn’t exist yet.

Which lands somewhere specific for anyone running these in production: a memory store that only ever grows is walking toward its own worst score. Every fact you never expire makes the next retrieval slightly worse. That’s not a model problem to be fixed by the next release — it’s what happens to any index with no delete path, and it’s the reason production databases have had TTLs and archival tiers since long before any of this.

The 26 August deadline is the tell

Here’s the part that convinced me this is a structural problem and not a young-category problem.

OpenAI notified developers on 26 August 2025 that the Assistants API was deprecated and would be removed a year later. That deadline is 26 August 2026 — twelve days from today. Threads, in that API, are where conversation state lived. Real state, accumulated by real teams, for a year or more.

The migration guide’s line on it: “We will not provide an automated tool for migrating Threads to Conversations.” The recommendation is to move new threads onto Conversations and backfill older history as needed.

A full year of notice, from a company with enormous engineering capacity, and no automated path for the state. I don’t read that as neglect. I read it as an accurate reflection of what Threads always were — a convenience store attached to a session abstraction, never a system of record, never something with an export contract, because nobody designed it to be the place where the fact lives. When it turned out teams had been treating it as exactly that, the honest answer was that there’s no clean way out. (One correction, since a few write-ups got this wrong this week: this is OpenAI’s own platform. Microsoft has stated Azure OpenAI is not impacted by this deprecation.)

If your agent’s memory has no export path, no schema you control and no owner, you have the same exposure. You just haven’t hit your deadline yet.

We already solved this, in a different decade

Everything above is a database problem wearing new clothes.

Retention. Time-to-live. Source of truth. Reconciliation. Cache invalidation. Provenance. Every one of those disciplines exists because a previous generation of engineers got burned by a second copy of the data drifting away from the first. We wrote the rules down, put them in the schema review, and gave someone a job title for it.

Then memory shipped as a feature toggle and inherited none of it.

The failure mode is the oldest one on this site: a layer that everybody uses and nobody owns. It’s the same shape as the boundary nobody verified and the same shape as a supplier record that three systems write to and none reconcile. Memory is just the newest place to put an unowned copy of your data. The thing that makes it worse than a stale cache is that this cache argues back — it’s read by something that will confidently act on it, at speed, without flagging that the fact is four days old and came from an email.

An agent that acts on a stale belief isn’t malfunctioning. It’s working exactly as built, on the data it was given.

What to do before your agents get long-lived

Put a name on the store. One person accountable for what’s in it, the way someone owns the CRM. If you can’t name them in a meeting, that’s the finding — stop there and fix it, because everything below needs an owner to enforce it.

Write the retention rule before the first write, not after the incident. Default expiry on everything, with explicit exceptions rather than explicit deletions. A store with no TTL is a cache nobody invalidates, and it will quietly become your longest-lived copy of data you have deletion obligations on. That last part is worth raising with whoever handles your privacy program, because a fourteen-day agent session holding customer facts is a processing location most data maps don’t know exists.

Then draw the line between context and truth. Preferences, prior conversation, working notes — fine, let memory hold those. Authoritative facts — credit limits, entitlements, prices, account status, anything with a compliance consequence — never get cached in memory. They get read from the system of record at the moment of use, every time. This is the one rule that does most of the work, because it means a poisoned or stale memory entry can shade the agent’s tone but can’t outvote the database on anything that costs money. It’s the same data-contract discipline that makes any integration survivable, applied to a store most teams don’t realize they’re running.

Log every write with its provenance. When a belief turns out to be wrong, you need to answer two questions fast: where did this come from, and what else did it touch. The MemGhost result makes that non-optional — an attack whose payload is a single write is one you can only investigate through the write log. Pair it with scoped identity per agent so a compromised memory can’t be laundered into an action the agent had no business taking.

And run the export drill now, on a quiet afternoon, while nobody’s deadline is twelve days out. Pull everything the agent knows into a file you control. If that’s hard, you’ve learned the important thing about your vendor before they teach it to you.

The useful question to walk into Monday with isn’t what your agents can do. Ask what they currently believe, who told them, and when you last checked whether it was still true. Most teams can’t answer the first part, which makes the rest academic.

If a store like that is running in your stack without an owner, that’s the kind of layer I get called in to fix — usually after it’s already made a decision somebody has to explain.