Memory is the capability that makes an agent feel like a colleague rather than a tool, and it is also the one most likely to create a governance incident. Both facts have the same cause: memory means the system retains things about your business and the people in it, over time, in a store that someone has to be accountable for.
The useful way to think about it is not "how much can it remember" but "which specific facts have earned a place, and under what terms".
Five kinds, not one
"Memory" collapses several different things that behave differently and need different rules.
Short-term memory is the current task. What was said two steps ago, what the document contained, what the last tool returned. It exists for the duration of the work and then it goes. Almost nobody has a problem with this one.
Long-term memory is what carries between tasks. That this client prefers fixed-price engagements. That this supplier's certificates expire in March. This is where the commercial value starts.
Semantic memory is knowledge about how your organisation works. Your service catalogue, your evaluation criteria, your escalation matrix, your architecture principles. Curated rather than accumulated — this is closer to a knowledge base than a memory, and it should be treated like one, with owners and review dates.
Episodic memory is what happened before. This tender was pursued and lost, for these reasons. This citizen has contacted us three times about the same pothole. Episodic memory is what allows an agent to notice patterns nobody entered into a system deliberately.
Procedural memory is how a task is done here. The sequence of checks before a bid is submitted, the format a report must follow, the exceptions that apply to a particular department.
The distinction matters because the governance question is different for each. Semantic memory should be curated and versioned. Episodic memory needs retention limits. Procedural memory needs an owner who updates it when the process changes. Lumping them together as "the agent's memory" guarantees that the wrong rules get applied to at least three of them.
What is worth remembering
Good candidates share a property: they are facts about how the business operates that are expensive to rediscover and stable enough to still be true next month.
Approved architecture principles. Evaluation criteria for bids. Client project assumptions that were agreed and documented. The service catalogue. The steps in a defined workflow. Why a decision went the way it did.
That last one deserves attention. Most organisations lose their reasoning almost immediately — the decision survives in a document, the reasoning survives in the memory of whoever was in the room, and it leaves when they do. An agent that captures the reasoning alongside the decision is doing something genuinely valuable, and it is a use of memory almost nobody plans for.
What should not be stored
Some of these are obvious and still happen constantly.
Personal details picked up incidentally in conversation. Health, financial or family information that arrived in an unrelated context. Content from documents the person asking was not entitled to see. Conclusions the agent reached that were never verified, which then get recalled later as though they were established fact.
That last category is the insidious one. An agent infers that a client's budget is probably around a certain figure, stores it, and six weeks later states it as background. Nobody ever told it that. It inferred it, and the inference has quietly become a fact in the organisation's memory. Anything stored should carry its provenance and its status — observed, stated by the client, or inferred — and inferences should not be recalled with the same confidence as facts.
Also worth stating plainly: outdated assumptions are worse than no memory. An agent that confidently recalls a superseded pricing structure or a policy that changed last year is more dangerous than one that has to look it up, because the looking-up would have found the current version.
The POPIA dimension
For any South African organisation, agent memory is processing of personal information, and the questions are the ones POPIA already asks.
What is the lawful basis for retaining this? Is it adequate, relevant and not excessive for the purpose? How long is it kept? Can the data subject request access to it, and can it be corrected or deleted on request? Is it secured appropriately? Who inside the organisation can see it?
None of this is unusual — it is the same analysis applied to any data store. What is new is that the store is populated automatically, by a system that decided on its own what was worth keeping, which makes the "adequate, relevant and not excessive" test considerably harder to satisfy after the fact.
The practical implication is that memory should be an explicit design decision rather than an emergent property. Deciding in advance which categories of fact may be written, from which sources, with what retention, is a fundamentally different position to be in than discovering later what a year of accumulated memory contains. Our broader treatment of POPIA and AI covers the surrounding obligations.
Making it reviewable
A few design choices make the difference between memory you can govern and memory you cannot.
Store the source with the fact — who or what asserted it, and when. Label the confidence. Give every entry a retention period and enforce it automatically rather than by policy. Keep personal data separated from business knowledge, so that a deletion request does not require unpicking a single undifferentiated store. Make memory visible: someone should be able to look at what the agent believes about a client, a supplier or a case, and correct it.
That last capability sounds like a nice-to-have and turns out to be operationally essential. When an agent produces a strange output, the first diagnostic question is what it thought it knew. If you cannot answer that in under a minute, every investigation becomes an excavation.
How to start small
Start with no long-term memory at all. Run the agent stateless, giving it what it needs at the start of each task. A surprising number of workflows need nothing more, and you will have learned exactly which facts the agent kept having to be told.
Those facts are your first memory design. Add them as curated semantic memory — written by a person, owned by a person, reviewed on a schedule — rather than as anything the agent writes itself.
Only then consider letting the agent write. When you do, constrain it: a fixed set of fields, a defined source, a retention period, and a review queue where a person periodically looks at what it has been storing. The first time you read that queue you will find something you did not expect, and you will be glad the queue existed.
How CloudNala can help
We design agent memory as a governed data store rather than an emergent feature — deciding up front which categories of fact may be retained, where they come from, how long they live, who can see and correct them, and how personal information stays separable for POPIA purposes. In practice this usually starts by removing memory the system did not need, which is faster to build and much easier to defend.
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 AI Readiness Workshop or write to us at consult@cloudnala.co.za