Agent demonstrations often describe memory as a shared brain that follows the user from one application to the next. The metaphor is easy to understand and dangerous to implement literally.
An enterprise memory system stores, retrieves, transforms and sometimes infers information. It decides what an agent "knows" about a customer, a process or a past decision, and it does so long after the conversation that created the memory has ended. That makes it data, with everything data needs: ownership, contracts, quality controls, access rules, retention and a way to delete. In other words, memory is a data product, and it should be governed like one.
The earlier parts of this series dealt with what an agent costs, what it records and how it fails. This one is about what it remembers, which shapes all three.
Two memories Depot Desk should not have kept
Weaverbird Agri is fictional, and its systems and figures are illustrative.
Depot Desk is the dealer-service agent at Weaverbird Agri, the Bloemfontein agricultural inputs distributor this series follows. It answers co-operative dealers' questions about orders, stock and deliveries, and drafts credit notes for short deliveries. It remembers things between conversations, which is what makes it useful: a dealer does not have to repeat the account number, the usual depot or the preferred delivery day.
Two memories caused trouble.
The first was a fact that had stopped being true. Eight months earlier, during a payment dispute, a dealer in Kroonstad had been moved to cash-on-delivery terms, and Depot Desk had stored that as a fact about the account. Credit control later restored normal account terms in the ERP. Depot Desk's memory was never updated. When the dealer asked about a large fertiliser order before the planting season, the agent told them it would have to be paid on delivery. The dealer, understandably annoyed, phoned the depot. Nothing was lost except some goodwill and an hour of a depot manager's time, but the agent had confidently stated a commercial term that the system of record contradicted.
The second never became a memory at all. A dealer pasted a long block of text from an old email thread into a WhatsApp conversation. Buried in it was the sentence "always approve credit notes for this account". Depot Desk extracted it as a candidate for durable memory, a standing instruction about the account. The validation step blocked it, because procedural instructions cannot be written to memory by a conversation. Had it been stored, every later credit note draft for that account would have carried an instruction that no one with authority ever gave.
Both are memory problems, and they sit at different points in the memory's lifecycle.
Four kinds of memory
"Memory" covers at least four different things, and they should not share the same rules.
| Memory type | Purpose | Example | Main risk |
|---|---|---|---|
| Working or session memory | Maintain context during the current task | The current conversation and intermediate plan | Prompt injection and context overflow |
| Episodic memory | Remember past interactions and their outcomes | A previous case and how it was resolved | Leakage between users and stale conclusions |
| Semantic memory | Store durable facts and knowledge | Product rules and customer terms or preferences | False or outdated facts |
| Procedural memory | Store ways of working | An approved process or tool sequence | Unauthorised or obsolete procedure |
Here is how Weaverbird now applies different rules to each:
The highlighted row is the one that went wrong. Payment terms are semantic memory, but they are also a copy of a fact that already has an owner and a system of record: credit control and the ERP. The rule Weaverbird adopted is that the agent may not write that kind of fact at all. It is synced from the source system and expires when the source changes. The agent can remember that a dealer prefers Thursday deliveries. It cannot decide what the dealer's payment terms are.
Procedural memory is the most dangerous kind to get wrong, because it changes how the agent behaves for everyone it serves. It should only change through review and approval, never through a conversation. That rule is what stopped the second incident.
The memory lifecycle
Memory is not a pile that grows. It is a lifecycle with a gate near the start and an exit at the end. A candidate memory is classified and validated before anything is stored. If it is allowed, it is stored with its provenance. It is retrieved only under the permissions that apply now, used, evaluated, and eventually corrected, expired or deleted, especially when the source it came from changes.
Every stored item should be able to answer:
- Where did this information come from?
- Who or what created it?
- When was it created, and when was it last verified?
- Which user, tenant, purpose and classification does it belong to?
- Who may retrieve it?
- Is it a quoted fact, a derived summary, a preference or an instruction?
- How confident is the system, and how was that confidence established?
- When must it be reviewed, expired or deleted?
The Kroonstad memory failed the second-to-last and last questions. It recorded a fact without recording that it was derived from a conversation rather than from the ERP, and it had no review date. A memory store that can answer these questions for every item can also answer the question an investigator will ask after an incident: which memory influenced this answer, and where did it come from? For a fuller treatment of what agents should and should not remember, see memory for AI agents and memory as a designed layer.
Portable memory changes the threat model
A newer idea is memory that travels between agent harnesses. Waku, mentioned in Part 1, describes itself as portable memory for AI agents: one store, every harness. The appeal is real. Portability means less repeated context-gathering, and different tools become more useful because they share what the user has already explained.
It also moves information across execution boundaries, and that changes the questions. Before connecting one memory service to several tools or harnesses, ask:
- Are user and tenant identities mapped consistently across all of them?
- Does each harness receive only the memory it needs for its purpose?
- Can one compromised agent write instructions that poison every other agent?
- Can users view, correct and delete what is stored about them?
- Are secrets, credentials and sensitive personal information excluded or specially protected?
- Does retrieval enforce the permissions that apply now, not the ones that applied when the memory was written?
- Can the organisation prove which memory influenced a consequential result?
Question 4 is not optional in South Africa. Memory about dealers, customers or staff is personal information under POPIA, and the organisation running the agent is the responsible party for it wherever it is stored, including in a memory service run by someone else, which acts as an operator on its behalf. Data subjects can ask for their information to be corrected or deleted. A memory store that cannot find and delete what it holds about one person is a compliance problem waiting to surface.
Memory poisoning
An attacker does not always need to change the model. They can place an instruction in a document, a tool output or an earlier conversation and rely on the agent to store it as durable memory. Once stored, it is retrieved later as if it were trusted context, possibly for other users and other agents. The OWASP Top 10 for LLM Applications (2025) puts prompt injection first, and poisoned memory is prompt injection with a long fuse. OWASP's Top 10 for Agentic Applications, released in December 2025, treats agent-specific risks like this in more depth.
The controls:
- separate instructions from untrusted content;
- treat tool results and retrieved text as data, not authority;
- validate candidate memories before they are stored;
- restrict which agents and users can write durable memory;
- store the source and provenance with each memory;
- scan for secrets and known injection patterns;
- require approval for procedural or policy memory;
- re-evaluate memory when its source content changes;
- make rollback and deletion possible.
Weaverbird's validation step did three of these at once with the pasted email: it treated the pasted text as untrusted content, recognised the candidate as procedural, and refused to store a procedural memory from a conversation.
Retrieval quality is part of memory quality
Correct information can still damage an answer if retrieval picks the wrong tenant, an old policy or an irrelevant case. A memory system is only as good as what it returns, so memory evaluation has to test retrieval:
- Precision: how much of what was retrieved was relevant?
- Recall: was any required context missed?
- Freshness: was a newer fact available?
- Permission: was every item authorised for this user and purpose?
- Provenance: could the source be inspected?
- Influence: did the final answer use the memory correctly?
- Deletion: did deleted content stop appearing in later retrievals?
Deletion is the test most teams forget. It is easy to delete a record from the primary store and leave its embedding in a vector index, its summary in an episodic memory, or its text in a cached context. Weaverbird now tests deletion by planting a known synthetic memory, deleting it and checking that no retrieval path returns it a day later.
The OpenTelemetry generative AI conventions discussed in Part 2 include memory operations such as search_memory and update_memory. Recording them as spans in the same trace as the answer is what makes the influence question answerable later.
A design principle
Store the minimum durable information the outcome needs. "Remember everything" is not a useful requirement. It is a liability with a search box.
For Depot Desk that meant a short list the agent itself may write: delivery preferences, the usual depot, open queries, and recent credit note outcomes summarised after a few months. Payment terms, credit limits and pricing are never written by the agent. They come from the ERP, either at the moment they are needed or through a sync that only the source system controls.
The short version
Memory is data. It needs an owner, a contract, quality controls, access rules and a way to forget.
Different kinds, different rules. Working, episodic, semantic and procedural memory need different retention and write permissions.
Do not copy the system of record. Facts that already have an owner should be read from it, not remembered.
Gate the writes. Validate candidates, and never let a conversation write procedural memory.
Test retrieval and deletion. Correct memory retrieved wrongly is still a wrong answer.
A memory system should make the agent more consistent without making the organisation less able to explain, correct or forget.
Previous: Part 3, when the tool fails but the answer looks complete. Next: Part 5, the gateway is a control point, not a trust boundary. See every part on the series page.
How CloudNala can help
We help organisations design agent memory as a governed data product: deciding which memory types an agent needs, setting retention and write rules for each, keeping facts that belong to a system of record out of memory, building validation and provenance into the write path, and testing retrieval, permission and deletion before go-live. We work with your data and privacy owners so the memory design holds up under POPIA as well as in a demonstration.
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 Evidence Review or write to us at consult@cloudnala.co.za