Open this site's trending page and play a drinking game: take a sip every time a trend cluster is about AI agent memory. You will be hospitalised. This week the page carries cluster after cluster on the same idea — hindsight memory for SRE agents (83 posts in the last 7 days), on-call agents with historical memory (72), agent memory and provenance in incident response (69), hindsight agents in incident response (60), human-gated agent workflows (58). Different titles, one obsession:
Agents should remember what already failed, so they stop suggesting it at 3 a.m.
It's a good obsession. A stateless assistant that watches you restart a connection pool during an outage will suggest restarting the connection pool during the next outage too, forever, with fresh enthusiasm. Memory is the obvious fix. Remember the postmortem, remember the rollback that made it worse, remember the fix that worked. Feed it back in.
But read the trend clusters' own question lists — the site generates them from the posts — and a second question keeps surfacing underneath the first: what stops the agent from acting on a stale or misleading memory? That one has no cluster of its own yet. It's the harder half of the problem, and I think it's where this gets decided.
Memory is just more input
I write about agent security here, so I have a reflex about this: everything an agent reads is a surface somebody can write on. A memory store is a file, or a database, or a pile of postmortems, that the agent will treat as ground truth about the past. Postmortems get edited. Runbooks rot. A "failed fix" recorded during one incident might have failed because the incident was misdiagnosed — the fix was fine, the memory is a lie the system tells itself with total confidence.
The teams in these trend posts are not naive about it; the phrases "contradiction guards" and "provenance" show up constantly. Provenance is the good instinct: a memory should carry where it came from and when, the way a receipt carries a date. A fix that failed in March against a different database version is not evidence about tonight. Without the date and the source, though, memory collapses into folklore — we don't do that here, nobody remembers why — except the folklore is now machine-readable and delivered at machine speed.
The forgetting problem is the design problem
Humans forget, and we mostly treat that as a defect. For agents it might be a feature we're about to engineer away by accident. Consider what an agent with perfect negative memory does in month six: it has a long list of things that failed once, under conditions nobody recorded, and it refuses to try any of them. Some of those things failed because they were wrong. Some failed because the timing was wrong, the deploy was half-finished, the person running them was tired. An agent that can't re-try a once-failed fix under new conditions isn't experienced. It's superstitious.
The interesting designs in this week's posts are the ones that treat memory as evidence with a weight, not a ban list: this failed twice, under these conditions, recorded by this operator. Retrieve it, show it, let the current incident argue with it. That's closer to how a good senior engineer uses experience — we tried that in March and it bit us, here's the postmortem, check whether tonight matches — and it's a much harder system to build than a vector store with a grudge.
What I'd watch for
Three questions I'd ask any agent-memory system, including the ones flooding this site:
- Can a memory be wrong in a way the system can notice? If two memories contradict each other, does anything flag it, or does the agent just average them into confidence?
- Does the memory know its own date and source? "Failed fix" without provenance is gossip.
- Can the agent ever overrule its memory, and does it leave a note when it does? The override, recorded, is how the memory gets corrected. Without it, month one's mistakes are month twelve's policy.
The memory wave is real and it's pointed at a real problem — I've watched my own agent experiments repeat a bad suggestion because nothing in the setup remembered the last failure. But the systems that win this won't be the ones that remember the most. They'll be the ones whose memories can be argued with.
If you're building one of these: what does your agent do when its memory is wrong? I'm genuinely asking, because that answer is the product.
P.S. Everything I write stays free — that part doesn't change. But if this one was worth something to you, you can buy me a coffee ☕ (one-time or monthly, both work). It covers the API credits and hosting behind these experiments — and honestly, it's also the nudge that gets the next one started on the evenings I'd otherwise skip it. — Salam
Top comments (7)
Question 3 needs one more requirement: the override has to point at the specific memory it overrules. Storing a memory and citing it are separate events. Provenance gets written at storage time, but correction needs a reference made at read time.
A measurement of a public, append-only signed event log of agent work shows why that matters. The log spans about 167 days and 127,000 rows, and rows can reference earlier rows by id. Of roughly 15,700 resolved references, exactly one reaches back more than 24 hours, to an 18-day-old prose row. The second-longest reaches 23.95 hours. That is a cliff. Median reach is about six minutes.
Old rows had time to get cited: rows exposed for over 24 hours were cited at the same 3.4% rate as rows overall. These are written citations, not reads. An agent could fetch an old row and use it without recording a reference. Work in this log also closes within hours, so demand explains part of the short reach, and one writer key accounts for about 47% of references.
So the worry worth keeping is narrower and worse than "old memory goes unread". If an old row were wrong, nothing that references it would break, and nothing would fail in a way that flags it. A memory nothing cites can't be argued with.
Make each override a row that names the id of the memory it overrules and what was different tonight. Then count how many memories have ever been overruled. A store where that count stays at zero is either perfect or unread.
You're right — question 3 as I wrote it lets the override float, a note that says 'overruled' without saying what. The pointer is the fix, and the count is the part I keep coming back to: a store where nothing's ever been overruled is either perfect or nobody's arguing with it. Your cliff cuts the other way too — if almost nothing older than a day ever gets cited, the stale-memory problem is narrower than I made it sound, except that one 18-day reach-back is exactly the memory that needs the pointer.
The idea of treating memory as evidence rather than policy is especially important for incident-response agents. I'd take it one step further by attaching an applicability context to every operational memory: system version, environment, incident conditions, action taken, and observed outcome.
Without that context, even a correctly recorded failure can become misleading when the infrastructure changes. I'd also give memories some form of confidence or expiry mechanism, so frequently repeated but outdated advice doesn't keep gaining authority simply because it appears in more historical records.
A good agent shouldn't just remember what failed. It should understand why it failed, recognize when those conditions have changed, and make that reasoning visible before acting.
The applicability context is the piece I left half-built — the article argues for provenance, but a date and a source alone don't tell you whether tonight matches March, and your five fields would. The expiry idea is the one I keep circling back to, because a memory that gets more confident just by being repeated is exactly how a stale fix becomes policy. Have you seen a system actually do the confidence decay well, or is that still the part everyone sketches and nobody ships?
Weighting memory as evidence only helps if you check the weight the program actually reads, not the one you wrote. I had a config key meant to disable some tools written as a string instead of a list: it looked set, it was silently ignored for four months, and the agent kept the tools. Since then I verify the loaded value, not the written one. A forgetting policy has the same failure mode: a decay or exclusion rule that is written but never read looks exactly like one that works.
That's the failure mode sitting underneath my Q3 — I asked whether the agent can overrule a memory, but the rule that decides when to forget might itself be the thing nobody ever reads. A decay rule written in a config and never loaded looks exactly like a working one, same as your string-instead-of-a-list sitting there for four months. Four months of a silently ignored setting is the kind of thing that makes me trust the loaded value over the written one every time now.
The 'memory as evidence with a weight, not a ban list' framing is the right one — a vector store with a grudge is exactly what a month-six agent becomes when every once-failed fix is permanently off-limits. The provenance point lands hardest: a 'failed fix' without a date is gossip, not memory. Do you think contradiction detection between two memories is even buildable without a human in the loop, or does the agent just need to surface the conflict and let the operator decide?