Your Agents Don't Have a Memory Problem

The moment I started paying attention wasn't dramatic. No outage, no incident review. An agent I was working with — one of several I run in parallel, every day — suggested an approach we had abandoned weeks earlier. And it argued for it well. Confidently. With reasons.

The reasons were good. They were just old.

We had already tried that path. We'd found the problem with it, made a call, and moved on. The agent didn't know any of that, because the record of why we moved on lived in a session that had long since evaporated. So it did what any capable reasoner does with incomplete history: it re-derived the wrong answer, beautifully.

I lead product and engineering, and I build with AI agents daily. That moment bothered me more than it probably should have — not because the agent was wrong, but because of how it was wrong. It wasn't a hallucination. It wasn't forgetting. It was a confident, well-reasoned recommendation of a decision my own team had already reversed.

That's a different failure mode than the one the industry is racing to fix. And I couldn't stop pulling on the thread.

Where everyone is looking

If you follow the agent-memory space — and if you're responsible for an engineering org adopting agents, you should — the energy is overwhelmingly pointed in one direction: remember more. Bigger context windows. Better retrieval. Higher recall scores. Every benchmark, every launch post, every roadmap converges on the same implicit definition of memory: the ability to bring back what was said.

It's a reasonable definition. It's also the wrong one, and the gap between the two is where the real risk lives.

Here's the thing recall can't tell you: whether what it retrieved is still true.

A perfect recall system retrieves your March architecture decision flawlessly. It also retrieves the April decision that reversed it flawlessly. What it cannot do is tell the agent which one is current — because currency isn't a property of the text. Nothing in the March decision says "I've been replaced." It sits in memory looking exactly as authoritative as the day it was written.

Humans handle this without noticing. Ask a senior engineer about the March decision and they don't just recall it — they wince and say, "yeah, we walked that back in April, here's why." That wince is institutional memory. Not the file server. Not the wiki. The living knowledge of what still holds.

We have spent decades learning that companies lose that knowledge when the senior people leave. Now we're deploying agents that never had it in the first place.

Machine speed changes the stakes

A human who missed the April reversal propagates the stale decision at human speed — a comment in a meeting, a paragraph in a doc. Annoying. Correctable. Someone catches it.

An agent propagates it at machine speed. It writes the code. It updates the docs. It opens the tickets. And if you're running agents the way organizations are starting to — several in parallel, handing work to each other — the stale decision doesn't just move fast. It compounds. One agent's confident wrong answer becomes the next agent's trusted input.

This is the part I'd put in front of every engineering leader evaluating agent adoption: the risk profile of AI agents isn't primarily that they make things up. Modern models are better at that than their reputation suggests. The risk is that they inherit and amplify whatever your organization believes — including the parts your organization has already stopped believing, without leaving a machine-readable trace.

Your decisions have a lifecycle. Made, revised, superseded, sometimes reversed outright. Your memory systems treat them as immortal.

Six months down the thread

I went looking for the system that solved this and didn't find one. What I found instead was a market competing hard on a question — how much can you recall? — that quietly assumes the harder question is already answered. It isn't. What's still true? is a different problem, with different architecture underneath it, and almost nobody was building for it.

So I did what product and engineering people do with a problem they can't put down: I spent the next six months building, measuring, being wrong, correcting, and building again. Some of what I learned surprised me. Some of it contradicted things I'd said out loud with confidence — and there's a post coming in this series about exactly that, because the way we caught our own errors turned out to be the most convincing evidence for the whole thesis.

This series is that six months, written for the people who own the decision I now think every engineering org will face: not whether your agents get memory, but what kind — and whether that memory knows the difference between what was said and what still holds.

Next up: the reframe everything else followed from — why recall and currency are different problems, and why solving the second one changed how I think about the first.

---

The product that came out of those six months is flmnt — a memory layer for AI agents built around decision currency: what's still true, not just what was said. It's in private beta now. If this problem sounds like your problem, use code BLOG30 for a free month and go see whether your agents are re-deriving old answers too.