Ask a team what "give the agent memory" means and you will hear several answers. Remember this conversation. Remember this customer. Remember what worked last time. Know our policies. These are different problems, with different owners and different risks. Treating them as one — usually as a database the agent writes to and reads from — is how agents end up confidently repeating something that stopped being true months ago.
This note separates the problems, explains why a database is the wrong mental model, and sets out the patterns and rules the Guild works from when an agent genuinely needs to remember.
Four things people call memory
| Kind | Example | Who writes it | Where it belongs |
|---|---|---|---|
| Working context | The current task, the conversation so far, the documents in play | The session | The context window; summarised or discarded when the task ends |
| Knowledge | Policies, procedures, product information | Named owners | A governed knowledge system, answered from with citations |
| Records | Orders, tickets, balances, bookings | The systems of record | Queried live through tools, never copied |
| Memory | What the agent learned from its own interactions: preferences, past decisions, what worked | The agent | A memory store with provenance, expiry and permissions |
Only the last row is memory in the strict sense. Most of the trouble comes from keeping one kind in the place meant for another: records copied into a knowledge index go stale; an agent's own notes start to stand in for policy; everything kept in the context window makes the agent slower, more expensive and more easily distracted.
Why a database is the wrong model
A database stores what it is given and returns exactly that. A row is true until someone changes it. Memory behaves differently in four ways.
- The agent writes it. A memory entry is the agent's interpretation of something that happened, and interpretations can be wrong. A row from the billing system is evidence; a note the agent wrote about a customer is an opinion with a date.
- It is selective. Keeping everything is not memory; it is a log. The useful part is the decision about what is worth keeping.
- It goes stale. Preferences change, people leave, decisions are reversed. Memory without expiry becomes confident error.
- It changes behaviour. Whatever is retrieved shapes the agent's next action. Memory is part of the agent's behaviour, so it has to be tested, not just stored.
So the design question is not "which database?" It is five questions: what may the agent remember, how does it know where and when it learned it, when does it forget, who may see it, and how does a person correct it?
Merlin note — The first question I ask is not where a memory lives but what it will change. If a remembered fact cannot change a future action, the agent does not need to keep it.
Five patterns, simplest first
- No memory. Every task starts fresh, with knowledge and records supplied as needed. This suits most single-step work and is the safest default.
- Task summary. A long task keeps a running summary instead of the whole transcript. The summary ends with the task.
- Profile memory. A small set of named fields per customer or account — preferred language, preferred channel, an open commitment — which the agent can read and propose updates to. Structured, visible and editable.
- Episodic memory. A searchable record of past interactions: "the last time this supplier was late, what happened?" It needs provenance, expiry and permission filters as strict as any knowledge system's.
- Learned procedure. When an agent notices a way of working that succeeds, it does not keep it to itself. It proposes it as knowledge, and the owner of that knowledge approves or rejects it. Memory becomes organisational knowledge through a person, not by accumulation.
Move down the list only when the pattern above has demonstrably failed.
Design rules
- A write policy. Decide what the agent may remember and what it must never store: credentials, payment details, health information, anything the person would not expect it to keep.
- Provenance on every entry. The source, the time and the interaction it came from, so any answer can be traced back.
- Expiry and review. Every kind of memory has a lifetime. What needs to last longer is confirmed again.
- Permissions at retrieval. Memory about one customer never appears in a conversation with another. The filter is applied before anything reaches the model, exactly as for knowledge.
- The system of record wins. When memory and the CRM disagree, the CRM is right and the memory is corrected.
- Correctable and forgettable. People can see, correct and delete what an agent remembers about them, and retention follows the same rules as the source.
- Promotion needs an owner. Nothing becomes organisational knowledge without a named person approving it.
How it fails
| Failure | What you see | What fixes it |
|---|---|---|
| Stale memory | The agent acts on a preference or fact that has changed | Expiry, re-confirmation, the system of record wins |
| Cross-contamination | Details from one customer surface for another | Permission filters at retrieval; deliberate probe tests |
| Shadow policy | The agent follows its own notes over the approved procedure | Knowledge outranks memory; promotion through an owner |
| Hoarding | Everything is stored, retrieval returns noise, costs rise | A write policy; store decisions, not transcripts |
| Self-reinforcing error | A wrong note is retrieved, repeated and written again | Provenance; unconfirmed entries carry less weight; human correction |
| Invisible memory | Nobody can tell what the agent knows about them | A readable memory view; an audit of reads and writes |
Testing memory
Because memory is behaviour, it is evaluated like any other capability, with scenarios that check that the agent:
- recalls what is relevant to the task, and only that;
- does not recall what is irrelevant or expired;
- updates when the system of record changes;
- forgets when asked to;
- never leaks anything across customers or users.
Run them again whenever the model, the instructions or the memory design change. In the Guild's Evaluation Lab, prompt and memory evaluation is part of the experiments Merlin owns, and Sentinel owns the boundaries that memory has to respect. The Agent Production Readiness Kit shows where these scenarios sit in a full scorecard.
An example
Illustrative example, not a client engagement.
A support agent for a subscription business. Its working context is the ticket and the conversation. Its knowledge is the refund policy and the troubleshooting guides, answered from with citations. Its records — subscription status and invoices — are queried through the billing tool and never copied. Its memory is a profile with three fields (preferred language, preferred channel, and any open promise such as "we will call back on Thursday"), each dated and expiring after thirty days, plus a record of past tickets that can be retrieved for the same customer only.
When the agent notices the same workaround solving a recurring problem, it drafts an addition to the troubleshooting guide. The support lead approves or rejects it. Nothing in this design is a clever database. It is a set of decisions about what the agent may keep, for how long, for whom, and who can correct it.
Where this sits in the Guild's architecture
In the Citadel, memory belongs to the agent layer — roles, tools, memory and limits — and sits beside the knowledge layer of approved sources, not inside it. Atlas maps the data and knowledge an agent acts from. Memory architecture is designed as part of a reasoning system in AI engineering, and the knowledge side is covered in depth in Building a Production AI Knowledge System.
