"Our agent has memory" has become a selling point. In a demonstration it usually means the agent remembers that you prefer email to SMS, or that you asked about the same street last month. That can be useful. It is also the least important of the three things that get called memory, and the one most likely to raise privacy questions.
What an operational agent needs first is state. It needs to know where it is in the current run, so that an interruption does not cause it to repeat an action. And it needs a record of the case it is working on, so that people can see what was decided and why. Neither of those is "memory" in the marketing sense, and both are often missing from systems that boast about recall.
This part separates the three, using Ubuntu Municipal Services, the fictional municipal entity in this series. Our series Memory Is an Architecture Decision goes much deeper on long-term memory; here the aim is to help buyers and approvers ask the right question.
Three scopes, three purposes
Run state is the progress of one attempt at a task: which step the agent is on, what each tool returned, how many retries it has used. It lives for minutes or days, until the run ends. The runtime writes it automatically at each step, as a checkpoint. If a run is interrupted, the checkpoint lets it resume from the last completed step rather than starting again.
The case thread is the record of one piece of work from start to finish: the resident's messages, the agent's actions, any approvals, and the outcome. It lives for the life of the case and then follows the organisation's retention rules. The case system writes it with every action. It is how a supervisor answers "what happened with this complaint?"
Long-term memory is what persists across cases: a resident's preferred channel, an address that is known to be mislabelled on the schedule, a lesson about a particular route. It lives for months, should have review dates, and should be written only under a governed policy. We set out those rules in Memory write policies matter more than the database.
Why state comes first
Consider what happens when each one is lost.
If Ubuntu's agent loses long-term memory, it asks the resident for their preferred channel again. Mildly annoying, entirely safe.
If it loses the case thread, nobody can see what was promised to the resident, a supervisor cannot review the decision, and the next complaint about the same street is treated as the first. That is a service and accountability failure.
If it loses run state in the middle of booking a re-collection, it may not know whether the booking succeeded. Without a checkpoint and an action that is safe to repeat, it might book a second truck. That is an operational failure with a direct cost.
The order of investment should follow that order of harm: run state and safe-to-repeat actions first, case thread second, long-term memory last. Many products arrive in the reverse order, because long-term recall demos well and checkpoints do not. We covered the run-state problem for long processes in An agent without durable state cannot own a long-running process.
What a checkpoint should contain
For a buyer or reviewer, it is enough to check that each checkpoint records:
- the goal and the case reference;
- the last completed step and its result;
- any action that was started but not confirmed;
- retries used and limits remaining; and
- the versions of the instructions, tools and policy in force for this run.
The fourth item is the one that prevents double actions. The fifth is the one that lets you explain a run later, after something has changed.
Long-term memory is a data-protection decision
Most of what an agent might remember about a resident is personal information. Under POPIA, keeping it requires a purpose, a lawful basis, a retention limit and a way for the person to see and correct it. An agent that silently accumulates notes about residents across complaints is building a profile that nobody approved.
Ubuntu's rule is simple. The agent may remember a resident's preferred channel, with the resident's agreement, for a defined period. It may record a schedule or address error as an operational fact about the property, not about the person. It may not record opinions about residents, their behaviour or their complaint history beyond what the case system already holds under its own retention rules. Our article Agent memory, POPIA and South African organisations covers the legal side in more depth. This is general information, not legal advice.
Isolation between cases
The final question is whether anything from one case can leak into another. In multi-tenant products, and in agents that serve many residents, that means checking:
- that retrieval for one case cannot return another resident's details;
- that long-term memory is keyed to the right person or property and nothing else;
- that summaries written for one case are not reused as context for unrelated cases; and
- that tests exist which try to make the agent reveal another case.
A supplier who cannot show isolation tests has not finished the memory design, however good the recall looks.
Questions to ask
- When you say memory, which of the three scopes do you mean?
- Where is run state stored, and what happens if a run is interrupted mid-action?
- Can a supervisor see the full case thread, including the agent's actions?
- What may be written to long-term memory, by whom, and for how long?
- How can a resident see, correct or delete what is remembered about them?
- Show me a test that tries to leak one case into another.
Key points
- Run state, case thread and long-term memory are different things with different owners and lifetimes.
- Losing run state can repeat actions; losing the case thread breaks accountability; losing long-term memory is usually safe.
- Invest in checkpoints and safe-to-repeat actions before recall.
- Treat long-term memory about people as a personal-information decision with a purpose and a limit.
Next: Part 6, Human-in-the-loop is not a button. All parts are on the series page.
How CloudNala can help
CloudNala reviews how agents hold state and memory. We check checkpoints and resumption, test actions for safe repetition, review what is remembered against POPIA purposes and retention, and run isolation tests between cases, leaving you with a state and memory design you can 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 Agent Due-Diligence Review or write to us at consult@cloudnala.co.za