Everyone is racing to make AI smarter.
Almost nobody is asking what it's allowed to remember.
I'm starting a daily series on the least understood layer in AI. Day 1.
Here's the confusion at the center of it: we've started calling the context window "memory." It isn't.
A context window is a desk. You pile things on it, you work, and at the end of the session someone clears the desk. Bigger models just give you a bigger desk.
Memory is the filing cabinet. What survives the desk being cleared.
So picture hiring a brilliant analyst with no long-term memory. Every morning you re-brief them on the company, the customers, the decisions you already made together. They nod. They do genuinely excellent work. And by tomorrow, it's gone.
You'd never call that person a knowledge worker. You'd call it a very expensive Groundhog Day.
That is most "AI agents" running in production today.
The industry's answer has been to treat this as a storage problem. Bigger context. Another vector database. Stuff more in, hope the right thing comes out.
I think that's the wrong frame entirely. Memory isn't a storage problem.
It's a trust problem.
Tomorrow, Day 2: why RAG is not memory — and why confusing the two costs teams more than they realise.
—
We at Alphanimble building Memuron, a memory system for AI agents. This series is the thinking behind it, in the open. Every post is something I've had to figure out to build the thing.
Top comments (6)
This distinction is becoming really important with coding agents. A larger context window can preserve more information temporarily, but that doesn't necessarily give the agent durable project understanding.
The interesting part for me is what happens outside the context window: architectural decisions, constraints, failed approaches, and the reasoning behind them. Those are the things an agent needs to recover across sessions, not just more tokens.
I think the harder problem is making that persistent context stay trustworthy as the project changes.
The failed approaches point is the one I'd underline hardest.
Most systems store what was decided and lose why the alternatives were rejected. So six weeks later the agent cheerfully re-proposes the thing you tried in March and abandoned for good reasons — and it looks like a fresh idea, because the record of why it died was never kept. Negative knowledge is the highest-value thing in a project's history and the first thing everyone drops.
And your last line is the actual hard problem, yeah. Durable context isn't hard to store, it's hard to keep true. A decision made under constraints that no longer hold is worse than no memory, because it carries the authority of having been deliberate — nobody re-examines it, it just gets cited.
Something has to notice when the ground moved. That's most of what I'm working on.
What are you building?
I'm building Xeyria — a project intelligence layer for AI-assisted development.
The goal is to preserve more than just project history: decisions, constraints, failed approaches, evidence, and the reasoning connecting them.
The part I'm most interested in is exactly what you described: knowing when previously valid context has become questionable. A decision shouldn't remain authoritative forever just because it was once deliberate.
So we're exploring how project context can carry not only what we know, but also why we believe it, what evidence supports it, and when it may need to be revisited.
I really like your framing of negative knowledge as high-value. “Why we didn't do this” may be just as important as “what we decided to do.”
Yes — I think that’s the distinction that matters.
Time can be a useful signal, but it shouldn't be the reason a decision becomes stale. If a decision was made because of a specific constraint, the interesting trigger is when that constraint changes.
That makes staleness less like “this memory is old” and more like “something this decision depends on has changed.”
I’d be really interested in how you approached that in Memuron. Especially how you detect that the reason behind a memory has changed, rather than just detecting that the memory itself is old.
I’ll definitely take a look at Memuron.
Agreed on the framing.
Honestly, I think most of the difficulty sits upstream of detection. At the moment a decision gets made, nobody is thinking about what it assumed. The constraint is obvious to everyone in the room, so it goes unsaid , and six months later the constraint has moved and the only surviving record is the conclusion.
So for me it's a capture problem before it's a detection problem. Everything downstream depends on whether anything was there to work with in the first place, and the answer is usually no.
How we approach it in Memuron isn't something I want to compress into a comment thread, happy to talk it through properly whenever you like.
But I'd be interested in where you land on capture. That's the one I don't think either of us gets to skip.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.