When to Turn Agent Memory Off, and What to Do Instead

What people are actually complaining about

The instinct to disable memory usually follows a specific experience. The agent asserted something confidently that used to be true. It kept proposing an approach you abandoned two months ago. It applied a convention from a different project. It referenced a decision that was reversed.

None of those are memory failing. They are memory working exactly as designed on content that should not have been retained, or should have expired.

That distinction matters because turning memory off treats the symptom. What you get is an agent that no longer surfaces stale facts and also no longer knows anything, which means you go back to re-explaining your project at the start of every session and paying for that re-explanation in tokens and attention.

So the useful question is not whether memory should exist. It is what earned a place in it.

The three categories, and what to do with each

Derivable facts. Anything that exists in a file: the module layout, the test command, the API surface, the conventions, the current configuration. These should never be persisted as memories, because the file is the source and the file changes. A memory that says the service uses one queue will outlive the migration that replaced it, and it will be recalled with the same confidence afterwards.

Retrieve these instead. RDK indexes files from local vaults, docs, and code as encrypted private chunks that agents search before querying a model, so the answer comes from the current file rather than from a snapshot of it. Token spend drops 80 to 90 percent on repeated or reference-heavy work because the answer is retrieved instead of regenerated, and staleness stops being a category of failure because there is nothing to go stale.

Genuinely durable facts. Preferences, standing constraints, and decisions with their reasoning. Small, curated, deliberately written, and worth reloading every session. If this set has grown past a page, most of it belongs in the first category.

Session context. What is happening right now. Useful until the task ends, then worthless, and it should expire rather than accumulate.

The common failure is treating all three as one store, which is how a system ends up recalling a file summary from March with the same authority as a standing constraint you wrote deliberately.

The case where turning it off is correct

There is one situation where disabling memory is the right immediate action rather than a blunt instrument.

If your agent writes memories from content it processed, rather than only from what you told it directly, then any text it reads can become a durable fact. A web page, a ticket, a dependency's documentation, a file in a repository you did not write. An instruction embedded in that content becomes a trusted memory, and on a later run it arrives from your own store where nothing marks it as external.

That is injection with persistence, and it is the hardest variant to detect precisely because the content is no longer coming from outside by the time it acts.

Until you can record provenance for every stored fact, and treat anything derived from external content as untrusted when it is retrieved, turning off automatic memory writing is a reasonable control. Keep manual memory, where you decide what gets written, because that path does not carry the same risk.

The permanent fix is provenance rather than abstinence: record where each fact came from, mark externally derived content, and re-evaluate it at retrieval rather than trusting it because it lives in your store.

A working configuration

Persist only what passes a narrow test: would this still be true and worth knowing next month, and could it not be cheaply re-derived from a file? That rules out most of what agents want to save.

Expire deliberately. Tag each durable fact with how it stops being true, by event or by time, at the moment you write it, because you will not be able to infer it later. Then run an occasional review over the standing set and delete what no longer holds.

Index everything else. Documents, code, decisions, and notes belong in a retrieval layer rather than a memory store, where they stay current because they are the source rather than a copy of it. Stacked retrieval sets the proportions in practice: a private vault answers 40 to 65 percent of queries, the public network adds 15 to 20 percent, and the model handles the remaining 5 to 10 percent.

And keep session state separate and short-lived, so that finishing a task actually clears it.

That arrangement gives you what people want from memory, which is an agent that does not need re-explaining, without the failure mode that makes them want to switch it off.