Four kinds of agent memory, and why they need different rules

Ask a product team what their assistant "remembers" and you will often get one answer: "the conversation and some customer details". Ask a different question, such as who is allowed to change each thing it remembers, and the answers divide quickly. The order number is set by the workflow. The customer's language preference came from the customer. The rule about when a refund is allowed came from a manager, last year, in a document nobody has opened since.

Those are different kinds of memory. They should live in different places, be written by different parties, last for different periods and be corrected in different ways. A design that puts them all in one store, under one set of rules, applies the wrong rules to most of what it holds.

CloudNala has introduced memory types before, in memory for AI agents and memory as a governed data product. This part goes a level deeper: for each kind, the concrete design decisions, using Sunbird's support assistant.

A helpful employee, as a model

Sunbird Home is fictional, and its systems and figures are illustrative. Think about a good support agent on Sunbird's team. During a call, she keeps the order number and where she is in the process in her head. She can look up the customer's previous cases. She knows a few things about regular customers, such as that one prefers WhatsApp. And she knows the company's procedure for late deliveries, because it is written down and she was trained on it.

She does not remember every sensitive detail forever. She does not treat a conversation from last year as current policy. She does not tell one customer about another customer's case. An agent's memory needs the same distinctions, and the four kinds below are a practical way to draw them.

The four kinds

The table is the easy part. The design is in the labels on each drawer.

Working state: the cheapest kind

Part 1 covered this in detail. It lives in a session store, is written by the workflow, lasts hours and is corrected by being overwritten. The only decision that tends to cause trouble is expiry. Sunbird chose 48 hours after the last message, because customers often come back the next morning. A team that never sets an expiry has quietly turned working state into a long-term store.

Episodic memory: the case file

Episodic memory records what happened: a previous complaint, a promise, an escalation, how a case was resolved. In a well-run support operation, this already exists. It is the case history in the helpdesk system.

That is the first design decision. Sunbird did not build a new episodic store for the assistant. It gave the assistant read access to the existing case history, through the same permissions a support agent has, and a single write path: when a case closes, the closure step writes a short structured record (what was asked, what was done, what was promised). The assistant does not write episodic memory from its own reading of a conversation.

The reason is accountability. When Zanele says "your supervisor promised me a refund of the delivery fee", the assistant needs to find that promise in a record a person made or approved, not in a summary a model produced. Episodic memory that the model writes for itself is a record of what the model thought happened, and those can differ.

Episodic memory also needs a retention period that someone has decided on purpose. Sunbird keeps case history for a period set by its own records policy, and the assistant sees only what that policy keeps.

Semantic memory: what we believe is still true

Semantic memory holds facts and preferences that carry from one interaction to the next. This is where most of the value of "a personalised assistant" sits, and most of the risk.

The useful test is whether the fact already has an owner. Zanele's delivery address has one: the order system. Copying it into a memory store creates a second version that will eventually disagree with the first. Sunbird's rule is that the assistant references facts that live in a system of record and only stores things that have no other home, such as a stated preference for WhatsApp updates or for deliveries after 3pm.

Every stored item carries where it came from, when, and through which channel. Part 4 sets out the write policy that decides what gets this far, and why a preference the customer stated is a different kind of claim from a conclusion the model reached.

Semantic memory is corrected by the person it is about. If Zanele says "actually, email is fine now", that replaces the old preference, and the old one is not kept "just in case".

Procedural memory is really versioned business policy

Procedural memory is how a task should be done: the steps for a delayed order, the conditions for a refund, when to escalate. It is the kind most often mishandled, because some designs let an agent "learn" procedure from experience. An agent that notices supervisors often approved early refunds may start offering them, and it now operates a refund policy nobody approved.

Sunbird treats procedure as what it actually is: business policy. It lives in a policy repository, not in the memory store. It has an owner, the customer experience manager. It has versions, effective dates and a review step before each release. The assistant reads the current version and records which version it applied to each case.

On 1 September 2026, Sunbird moved from version 3 to version 4 of its delayed-order procedure. Under version 3, a customer could cancel for a full refund once an order was ten working days late. Version 4 lowered that to seven working days, and added a step: open a courier query before offering anything. Because each case records its version, a promise made under version 3 on 31 August was still honoured, and cases from 1 September onwards used the new rules. Nothing the assistant had seen in older cases could override version 4.

This is the clearest example of a broader rule: if changing a memory would change how the system treats everyone, it is not memory, it is policy, and it needs policy controls.

The awkward cases

Real information does not always sort cleanly. Three cases came up at Sunbird:

• "Zanele was very upset last time." This is episodic, but it is also an opinion about a person, and POPIA's definition of personal information includes "the views or opinions of another individual about the person". Sunbird does not store emotional assessments in customer memory. If a case needs care, the closure record says what was promised, not how the customer felt.
• "The courier is unreliable in Gqeberha." Useful, but it is operational knowledge about a supplier, not memory about a customer. It belongs in a supplier performance report owned by the logistics team.
• "She uses a wheelchair, deliver to the ground floor." The delivery instruction is useful. The reason is health information, which POPIA treats as special personal information. Part 6 shows how Sunbird keeps the instruction without the reason. (This is general information, not legal advice.)

If an item does not fit a drawer, that is a signal to stop and decide, not to create a fifth drawer called "other".

Key points

Memory is four things, not one. Working state, episodic, semantic and procedural memory need different rules.

Reuse the case file. Episodic memory usually exists already, in a system with an owner.

Reference facts, store only what has no home. Copies of system-of-record data drift.

Procedure is policy. Versioned, owned, reviewed and never learnt from conversations.

Awkward items are decisions. Opinions, supplier knowledge and health details belong somewhere else, or nowhere.

Next: Part 4, Memory write policies matter more than the database. All parts are on the series page.

How CloudNala can help

We help teams map what their assistant remembers today into these four kinds, find the items with no owner and the procedures being learnt rather than approved, and design where each should live. Often the outcome is less new infrastructure than expected, because the case file and the policy repository already exist.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an Agent Memory Review or write to us at consult@cloudnala.co.za