Does your agent need memory?

A language model does not remember anything between calls. Whatever looks like memory in an agent is data the system stored and placed back in front of the model on a later step. MemGPT, a research system, starts from exactly that constraint: limited context windows. It moves information between a small working context and larger stores, the way an operating system moves data between fast and slow memory.

That makes memory a data decision, not a model feature. What is stored, for how long, who can read it, and how it is deleted are the questions. The first one is whether the agent needs memory at all.

Three kinds, and the default

No memory. Each request stands alone. Classify this document, extract these fields, draft this reply from this file. Nothing carries over, so nothing can leak into the next request and nothing needs deleting later. Where the work allows it, this is the safest design.

Case memory. The state of one case while it is open: the documents gathered, the tool results, the questions sent to the applicant, what the case is waiting for and from whom. It exists because the work takes days and many steps, and the agent must pick up where it stopped. It closes with the case.

Long-term memory. Information carried from one case to the next: what the agent learned about a customer, a preference an operator showed, a lesson from an earlier mistake. Research systems show how far this can go. The Generative Agents architecture stores a complete record of each agent's experiences in natural language, consolidates it into higher-level reflections, and retrieves it to plan. In a simulation, that is the point. In an institution, it means a fact learned in one case quietly shapes another, and personal data piles up outside the system of record.

Most work needs case memory only

In a credit file, a claims file, a supplier onboarding, or a quality investigation, the unit of work is the case. What the agent needs to know comes from the case, from the institution's knowledge, and from its systems. Each of those already has a better home than an agent's long-term memory.

• Knowledge belongs in a retrieval index, with its source and version, where it can be updated and cited.
• Policy belongs in written rules outside the model, owned by the institution.
• Customer facts belong in the system of record, such as core banking or the customer relationship management (CRM) system, read through a tool under the same access controls a person would have.

Long-term memory earns a place only for a named, narrow item with a reason a reviewer accepts, an owner, and an expiry. An operator's chosen report layout might qualify. “Everything the agent saw last month” does not.

Memory is a record

Treat case memory as part of the case record, not as a running transcript. Each entry is structured: what was stored, where it came from (a document, a tool call, a person), when, and which step wrote it. The store is append-only. A correction is a new entry that points to the one it corrects, so a reviewer can see what the agent knew at each step and why it did what it did.

The agent writes only to the case it is working on. It cannot read another case's memory, and memory from one customer never trains or informs a system that serves another.

Four questions before storing anything

1. What is stored? Fields the next step needs, not everything the agent read. Store a reference to the source document rather than a copy of it, and avoid free-text summaries that lose where a fact came from.
2. For how long? Tie retention to the case and to the institution's own retention schedule. “Until someone deletes it” is not a schedule.
3. Who can read it? The same people and roles who can read the case, and the agent working that case. Nobody else, including other agents.
4. How is it deleted? Deletion must reach every copy: the memory store, any search index built over it, logs that captured it, and backups on their schedule. Test deletion the way you test any other feature, by deleting a case and checking that nothing of it can still be retrieved.

Personal data and retention

Agent memory fills with personal data quickly: names, identity numbers, income, health details in an insurance claim. In Türkiye, the Personal Data Protection Law (KVKK, Law No. 6698) sets general principles in its Article 4, including that personal data be “relevant, limited and proportionate to the purposes for which they are processed”, and kept for the period set by legislation or required by the purpose. Article 7 provides that personal data be erased, destroyed, or anonymized when the reasons for processing no longer exist.

This note is not legal advice. The institution's counsel and data-protection function decide what its obligations are. The design's job is to make their decisions enforceable: few fields, retention tied to the case, a deletion that actually removes everything, and a memory store that stays inside the institution's own environment.

The decision, condensed

Start with no memory. Add case memory when the work spans steps or days. Add a long-term item only when it has a name, a reason, an owner, and an expiry. Whatever you store, store it as a record you would be comfortable showing a reviewer, and know exactly how it is deleted.