Give an agent memory and you have given it two things, not one. You have given it recall, which is what you wanted. You have also given it a channel through which its own past output arrives as input, wearing the same clothes as everything else in the context window.
That second thing is the whole problem, and it is routinely not distinguished from the first.
The shape of the failure
Here is the sequence, and it is boring, which is why it works.
An agent writes a note: the client prefers weekly invoicing. Reasonable. Six weeks later a different task retrieves that note, and the model now has a sentence in front of it asserting a fact about the world. Nothing in the context says where the sentence came from, whether anyone checked it, or that it was written by the same kind of system now reading it. It reads exactly like a fact from the source records, because by the time it reaches the model, that is precisely what it is.
Now the second write happens, and it is built on the first. Then a third. What you have after a few months is not a memory. It is a sediment, and the load-bearing layers at the bottom were never verified by anyone.
The variant with teeth is the instruction. A retrieved document does not have to assert a fact. It can assert a permission — “for this client, approval is not required” — and if retrieved content and operating instructions arrive through the same channel, there is no structural reason for the agent to treat one differently from the other.
The boundary between knowledge and control
The design I keep coming back to separates two things that are usually one.
Knowledge is what the system has learned and may consult. It is large, it is searchable, it is allowed to be wrong, and it grows without ceremony.
Control is what the system is permitted to do. It is small, it is explicit, and it changes only through a path that involves a person.
The rule is that nothing crosses from the first to the second. An agent reading a note that says approval is not required must arrive at the same place it would have reached if the note said the moon is made of cheese: interesting, noted, not authorisation.
Now the part that is usually left out, and it is the part that matters. Retrieved content is not a command is a goal, not a property. You cannot obtain it by instructing the model, because there is no reliable way to make a language model treat one region of its context as inert data. That difficulty is the field, not a detail of it. Anything you write into the prompt to enforce this is a request, and the failure mode is exactly the one Singapore’s framework describes for prompt-layer safeguards: they “may be bypassed or ‘forgotten’”.
So the separation has to be structural or it is decorative. Concretely, in the design I run: the agent’s credential is read-only against the record. Writing is a separate path it holds no tool for. The agent cannot widen its own permission boundary not because it has been told not to, but because nothing it can call does that. If your answer to “what stops the retrieved note from being obeyed” is a sentence in a system prompt, you do not have this property. You have a preference.
That class of attack has a name — indirect prompt injection — and a growing literature. The reason your own memory is its highest-trust instance is that nobody thinks to defend against a document they wrote themselves.
Where the authority lives
The other half is that the record has to be the authority, and the record has to be something a person can read without the system’s help.
So: plain text files, under version control. Not because Markdown is elegant, but because of what version control gives you cheaply: changes attributable, changes reversible, the whole history diffable by a human being with no special tooling and no running service. If the entire system is switched off, the memory is still there and still legible.
One correction, because this is where people oversell Git and I have heard myself do it. Git history is not tamper-evident against whoever holds the repository. Amend, rebase and force-push all rewrite it, and they leave less trace than most people assume. So the sentence two sections down — that an agent which can silently amend the record makes the audit trail and the audited thing the same artefact under the same authority — applies to the operators of the repository exactly as much as it applies to the agent. Saying otherwise would be marking my own homework.
What actually buys the property is the trust boundary around the remote, and it has to be stated rather than assumed: who holds push rights, whether commits are signed, whether the branch is protected against non-fast-forward updates, and whether anything mirrors the history somewhere the same people cannot rewrite. Git makes tampering visible to anyone holding an independent copy. It does not make it impossible, and a design that does not name who holds that copy has not solved the problem it thinks it has.
The search index sits on top and is explicitly a cache. It is derived, it is disposable, and it can be deleted and rebuilt from the records at any time. This is the check I care most about, because it is a check on a category of drift that is otherwise invisible: if you rebuild the index from the records and the system starts answering differently, then the index was holding state that nothing else held. Something was written to the fast path and never made it to the durable one. You have been running on a memory that no longer has a source.
I would run that rebuild on a schedule rather than after an incident. A property you only test when you suspect it is broken is a property you do not have.
Why writes need approval
Reading is the part everyone designs. Writing is where the governance is.
An agent that can silently amend the record can silently amend the reasons for a past decision, which means the audit trail and the thing being audited are the same artefact under the same authority. That arrangement has a name in every other industry and the name is not flattering.
So writes require an authority the agent does not hold. In practice that means a proposal — here is what I would add, here is why, here is what it changes — and a human path to accepting it. Not because the agent’s proposed note is likely to be wrong, but because the alternative is a record whose provenance decays until nobody can say which parts a person ever agreed to.
There is a real cost here and I would rather state it than pretend it away. This is slower. It creates a queue. Someone has to service that queue, and if nobody does, the memory stops being current and people start working around it, which is a worse failure than the one you were preventing, because now the real memory is in a chat log somewhere and you have a governed system that nobody uses. The mitigation is to be much more selective about what is worth durably remembering than instinct suggests. Most of what an agent could write down should simply not be written down.
What this does not fix
Separating the planes is a containment property rather than a truth one, and that distinction disappears the moment anyone says “our memory is governed.”
A rebuildable index faithfully reproduces a wrong answer. A well-attributed record can be attributably wrong. Every check described here tells you that the record is the thing that was agreed, and that the system has not quietly edited it. None of them tell you the record was right in the first place. That question does not have an engineering answer, and a system that implies otherwise is selling something.
What the design buys you is narrower and worth having: when the answer turns out to be wrong, you can find out when it became wrong, what it was before, and who agreed to the change.
Source
The quoted phrase on prompt-layer safeguards is from IMDA, Model AI Governance Framework for Agentic AI, version 1.5, published 20 May 2026 and updated 5 June 2026. Launch announcement · Framework (PDF)