"Give the agent memory" sounds like a capability decision. It is a data governance decision wearing a capability's clothes, and the difference shows up about four months in, when somebody asks what exactly the system knows about a client and nobody can answer.
We have written elsewhere about the kinds of memory an agent can have and what each is for. This article is about the layer in front of all of them: the rules that decide what gets in.
The gate is the design
Without something in that middle column, memory becomes an accumulating transcript. Everything said, kept indefinitely, retrieved later by relevance rather than by rule. It works well in a demo and degrades in a specific way: contradictions build up, outdated facts keep being retrieved with the same confidence as current ones, and personal information that entered the system in passing is now permanent and unfindable.
Five words are enough to specify the alternative.
Remember. What categories of fact may be stored at all. Not "whatever seems useful", but a list: client context, decisions taken, approved assumptions, next actions, outcomes. If a fact does not fit a category, it is not stored.
Ignore. What is explicitly excluded. Draft content. Anything a user marked as speculative. Personal information beyond what the workflow requires. This list should be written before the first one, because it is the one that keeps you out of trouble.
Expire. How long each category lives. A next action is stale in a fortnight. A decision might be relevant for years. A client's stated preference should probably be re-confirmed annually rather than treated as permanent.
Correct. How a wrong fact gets fixed, and what happens to the old one. Superseding is almost always better than silent editing, because the question "why did it say that in March" needs an answer.
Audit. Who can see what is stored, who can delete it, and where the record of both lives.
What each system should hold
Written this way, memory design becomes a short and quite boring document, which is the goal.
Lead triage. Opportunity owner, channel it came through, last action, next action, decision status. That is close to the complete list. Note what is absent: no conversation history, no draft emails, no notes someone typed while thinking out loud.
Tender work. Tender category, client, eligibility outcome, bid or no-bid decision, and the lesson learned. The last field is the valuable one and the one that requires a person to write it, because "we lost this because our B-BBEE position was misread by the evaluator" is not something the system can infer from the outcome.
Proposal and architecture support. Approved architecture assumptions, reusable patterns, known proposal risks. Again note the constraint: approved assumptions. An assumption an agent generated and nobody confirmed does not belong in memory, because retrieving it later gives an unreviewed guess the authority of an established fact.
That distinction between generated and confirmed is the single most useful rule in agent memory design. It is also the one most commonly missing.
Facts have a life, and most designs stop at birth
The expensive failures all live in the last three boxes, and they surface months later.
A fact was written in March. It has been retrieved into forty runs since. In August a reviewer corrects an output that depended on it, because the underlying situation changed in May. What happens next is the test of the design. In a system with no lifecycle, the correction fixes one output and the wrong fact stays, so the same error recurs. In a system with one, the correction reaches the memory entry, the entry is superseded rather than quietly overwritten, and the March version remains readable for anyone who needs to understand a decision made in April.
A memory with no expiry rule is a permanent claim that nobody ever re-checks. In a POPIA context that is not only a quality problem, it is a retention problem, and "we did not decide, it just accumulated" is a poor position to explain.
The personal information question
Worth stating separately because it is the one that carries legal consequence in South Africa.
Personal information entering agent memory must be separable, which means three things in practice: you can find every entry relating to a person, you can delete them, and you can say why each was retained. A vector store of undifferentiated conversation history satisfies none of those, and retrofitting them is considerably harder than designing for them.
The straightforward approach is to keep personal information out of the general memory layer entirely, referencing records in a system that was built to hold them rather than copying values across. It is less elegant and it is much easier to defend. Our note on POPIA and data strategy goes into this further.
Where to start
Counter-intuitively, the fastest way to a good memory design is to start with none.
Build the workflow with no memory at all and see what actually breaks. Usually three or four facts turn out to be genuinely needed across runs. Those facts are your first memory design: add them as curated entries, written by a person, owned by a person, reviewed on a schedule.
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 someone periodically reads what has been stored. The first time you read that queue you will find something surprising, and you will be glad the queue existed.
Practical checklist
- Write the ignore list before the remember list
- Name the categories of fact that may be stored, and store nothing else
- Give every category a retention period
- Distinguish agent-generated from human-approved, and only retrieve the second by default
- Supersede rather than overwrite, so history stays readable
- Keep personal information referenced rather than copied
- Build a review queue and actually read it
How CloudNala can help
We design agent memory as a governed data store rather than an emergent feature: which categories 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 the engagement usually begins by removing memory the system did not need, which is faster to build and much easier to defend later.
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