I watched one of our engineers explain the same validation pattern in Claude Code for the fourth time last month. Not because he forgot that he had explained it. Because the tool is forgotten.
Every session, from the beginning. “We use JWT authentication at the gateway, not at individual services.” He said it three days ago. And last week. And every time he started a new session in the last six months. Every time, the AI nodded, followed the instructions perfectly, and then forgot everything when the time ran out.
I kept thinking about this, because it felt like the kind of problem that needed to be solved. It is 2026. These models know the real thing. They can discuss complex basics, fix subtle race conditions, and write rigorous tests. And yet they operate with what I can only describe as aggressive amnesia – a pathological inability to retain anything past the current session.
An excuse for auto-complete
This made sense when AI coding tools were auto-completion engines. Copilot in 2022 was completing one line of code. The core was a single file. Why would it need memory? You type, it raises, you tab. Session memory is not important.
But these tools are no longer like that. We ask them to create features across multiple files. Fix production problems that require understanding the system architecture. They onboarded new developers to unfamiliar codebases. Automatically launch on GitHub issues. And every time, they start from zero.
I keep coming back to this analogy: imagine hiring a smart contractor who arrives every morning with complete amnesia. They can code. They are fast. But every day you spend the first hour explaining the project, team meetings, decisions you’ve already made, mistakes you’ve already learned from. And the next morning? Same thing.
That is what is happening right now. In all groups. With all the tools.
Things that don’t make it into code
This is what bothers me the most. The things that AI always forgets are not in the code. It’s the stuff that lives between the lines:
Why we chose Postgres over DynamoDB. (The performance of our query patterns, but also because the team has deep Postgres expertise and bare-bones DynamoDB experience.)
Why the notification service is a monolith module and not a microservice. (We tried microservices. It was a disaster. We’re back in Q3 and no one has written why.)
That the payment pipeline has a known limit where events are scheduled silently under heavy load. (Two developers know about this. One of them just gave notice.)
None of this is in the file that the AI can scan. Some of it was in a Slack thread for the past eight months. Most of it is in people’s heads. And it’s precisely the kind of context that determines whether an AI’s output is correct or subtly, dangerously wrong.
“Just put it in the configuration file”
I know what you’re thinking, because I’ve thought it too. CLAUDE.md. .cursor rules. System information. Just write it all down in a file and point the AI at it.
We tried. Everyone tries. And it works – for about three weeks, until the file gets old and nobody updates it because updating a fix file is a maintenance job that doesn’t ship features. The person who wrote the original file has moved on to other things. New decisions are made in discussions that do not make it to the file. The file becomes a historical artifact that closely resembles what the group believed at some point in the past.
It’s a wiki problem too. Man creates with good intentions. It starts to rot quickly. Within six months, developers are no longer trusting it because they are burned out following outdated information.
“Use a larger content window”
Another popular answer. 200K tokens weren’t enough, so now we have 1M. Just put everything in.
I’ve spent a lot of time thinking about this, and I think you’re fundamentally misunderstanding the problem. A larger context window gives you more space for the current session. It doesn’t give you memory. It doesn’t tell you why the team made a particular decision to build last quarter. He knows about a production incident that shaped the way the team thinks about error management. He doesn’t know that Sarah is the only person who understands the reconciliation process.
A bigger window is a bigger scratch pad. The scratch pad is still erased when time runs out. You haven’t solved the amnesia – you have given the amnesiac a larger notebook that is also burned every night.
“Just add more agents”
It’s the latter that gets me. The answer to “the AI doesn’t know enough” is obviously “add more AIs that don’t know enough, but give each one a smaller job.”
Review agent. A screening agent. Shipping agent. Fifteen special agents, each with hard-coded instructions for a single mission. Someone in the group wrote those instructions. Someone has to save them. When review standards change, someone updates the review agent. When the test framework changes, someone updates the test agent. It’s a configuration file problem at a higher release level, with more moving parts.
And you know that none of those agents know? Anything for your organization. They know what a person has strictly included in their instructions. They don’t know what the team learned last week.
It’s a question that keeps bothering me
Here’s what I keep coming back to: what if AI just… remembers?
It’s not a raw chat script. That’s the noise. But the real information – decisions, patterns, mistakes, agreements – extracted from the discussions and found in future sessions. Not just for the engineer who had the conversation, but for the whole team.
The developer explains why we use event detection in the research system. That definition becomes a structured information object – available to all other developers, in all future instances, except for whoever maintains the file.
Someone discovers a subtle conflict between two services while debugging. That discovery is being held. The next time someone touches any resource, the AI already knows about the pairing. Not because someone remembered to write it, but because the program was listening while the information was being created.
The AI that helped you fix a payment problem on Tuesday starts your Thursday session already knowing what you found. A new developer joining next month has an AI that knows everything the team has learned in the last year – from day one.
I think about this a lot because it changes what the tool is. It stops being a coding assistant and starts being an organizational memory. It’s not a wiki that anyone should care about. A living knowledge base that grows because people use the tool.
Where this goes
The market for AI coding tools is about to split. On the other hand: tools that help individual developers write code faster. These are for sale. Models are cheaper every quarter. The wrappers are getting smaller. No profit lasts long.
On the other hand: tools that make the collective intelligence of an organization available to all developers, all the time, forever. These are not available yet. Not really. Not in a really practical way.
I’ve been spending the last year thinking about what phase two looks like. How do you build? That should be architecture. When industry perceptions are wrong.
It all started with this one observation: your AI tool has amnesia, and no one seems to think that’s a problem worth solving.
I think that is the only problem that needs to be solved.
