Agent memory sounds useful until it starts remembering the wrong thing.
That is the failure mode I care about most. Not that an agent forgets something. Forgetting is annoying. Remembering a stale or false fact with confidence is dangerous.
For software work, memory without provenance is just vibes with a database.
What provenance means in practice
A durable memory item should be able to answer four questions:
- Where did this fact come from?
- When was it observed or decided?
- Who or what is allowed to use it?
- What would make it stale?
If a memory cannot answer those questions, it should be treated as a hint, not as context the agent may rely on automatically.
A software example
Imagine an agent remembers: "Do not touch the payment webhook retry logic." That sounds useful, but it is incomplete.
Was that decision from a production incident? A Slack thread? A senior engineer's review comment? A workaround from six months ago? Did the system change since then? Is the warning still true for all services, or only for one deprecated handler?
The useful version is different:
Payment webhook retry logic is sensitive because incident INC-184 showed duplicate fulfillment when retries were not idempotent. See PR #2317 and the runbook section updated on 2026-05-14. New retry changes need idempotency checks and staging replay before deploy.
Now the agent has a source, a reason, and a verification path. That is memory worth using.
Memory should decay
Most engineering facts have a half-life.
An API constraint may disappear. A launch freeze ends. A flaky test gets fixed. A manual deployment rule becomes automated. If memory never decays, it becomes a pile of old caution signs that slow the team down.
Good memory needs state: current, stale, superseded, archived, needs review. It also needs a way for newer evidence to challenge older memory.
Memory diffs are better than silent writes
I do not want agents silently writing long-term memory every time they finish a task.
I want a diff.
After a PR, incident, or debugging session, the agent can propose what it learned: new runbook rule, changed API behavior, updated deploy constraint, known gotcha, removed warning. Then a human can approve, reject, or edit it.
That keeps memory reviewable. It also forces the system to explain why something deserves to become durable context.
The real product is trust
Agent memory is not valuable because it stores text. It is valuable when it improves trust.
Can the agent show its source? Can it tell me what changed? Can it avoid leaking private context across projects? Can it admit when a memory might be stale?
If the answer is no, the memory layer is not helping enough. It may even be making the system worse.
The goal is not an agent that remembers everything. The goal is an agent that knows which facts deserve trust, and why.