Why AI Forgets

When people notice that AI systems "forget" between conversations, they usually reach for one of two explanations. Either the system is broken in some ordinary way — a bug in the product, a limitation of that particular vendor — or the model itself is not intelligent enough to keep track. Both intuitions are wrong, and both hide the more interesting truth. Modern AI does not fail to remember because it is careless or incomplete. It fails to remember because remembering, in the way humans do it, is not part of how these systems are built.

To see why, it helps to start with how humans do it, and then look at what is genuinely different underneath.

When a person works on a software project over weeks or months, they are not exercising some special faculty called "project memory." They are accumulating. Every meeting adds a decision, sometimes a small one — an endpoint gets renamed, a validation rule tightens, a queue does not get built again. Every argument leaves a residue. Every mistake teaches something narrow and specific: the retry policy on this integration must not be exponential, the enum on that column has one more value than the type says, this particular customer requires an invoice format nobody else does. Human memory is imperfect and lossy, but it is continuous. Understanding grows. What you knew last month is still there, in some form, informing what you decide today.

An AI system does not work this way, and it is important to be precise about what "does not work this way" actually means. It is not that the model is incapable of learning — training itself is a form of learning, and it is where nearly all of a model's capability comes from. It is that once a model is trained and deployed, the moment-to-moment thing you interact with does not update itself from your conversation. Nothing you tell it modifies its weights. Nothing you show it is added to a permanent store of what it knows about your world. There is no background process quietly integrating today's chat into tomorrow's understanding.

What the model does have — what makes the appearance of memory possible at all — is a context window.

The context window is the passage of text the model is actively looking at when it generates a response. It is the whole of what the model sees. Anything inside the window can influence the answer; anything outside it might as well not exist. When you paste in a file, or describe your architecture, or say "as we discussed earlier," you are putting information into that window. When you close the tab and open a new conversation, the window empties. The model has no other place from which to recover what was in it.

This is the technical heart of why AI seems to forget. It is not that the system had memories and lost them. It is that the system's only memory of your project was the text it could see, and the text is gone.

From this simple mechanism, a lot of familiar behaviour follows. Every response is generated against the current window and nothing else. Two identical prompts asked in two different conversations can produce two different answers, because the surrounding context is different. The moment a piece of information scrolls out of view — pushed off the end of the window by newer messages — it stops being usable, quietly, without warning. The model does not know what it has forgotten. From its point of view, there was nothing to forget. It was only ever looking at what was in front of it.

The word engineers use for systems that behave this way is stateless. A stateless system treats each request independently. Nothing carries over unless the request itself carries it. This is a design characteristic, not a defect. Most large-scale infrastructure on the internet is stateless for exactly the reasons that make it a useful shape: statelessness is simpler, faster, easier to scale, and easier to reason about. But when the thing being asked to behave this way is a collaborator on a long, evolving piece of work, statelessness becomes a real cost. Each new conversation is a fresh instance of a colleague who has never seen your project before, and there is no ambient way for them to catch up.

At this point most readers reach the same conclusion: this is a size problem. If the window is what limits memory, then bigger windows should solve it. A model that can look at more text at once should be able to hold more of your project at once. And larger windows do help, up to a point. They make it possible to review more of a codebase in a single pass, to keep a longer conversation coherent, to bring more supporting material into a single answer.

The first problem is that software projects grow without bound. A window that comfortably held your architecture at week two will hold a shrinking fraction of it by month six, and a smaller fraction still by year two. Codebases, decisions, and specifications accumulate faster than any window can be enlarged. You will not out-run the growth.

The second problem is subtler and matters more. Even when everything you need does fit inside the window, the model is not equally attentive to all of it. Information near the current focus tends to dominate. Information far away — the decision made twenty thousand tokens ago, the constraint mentioned once in an earlier turn — becomes progressively easier to overlook. Not because the model has "forgotten" it in the strict sense, but because the signal it contributes is drowned out by everything else. Reading is not the same as weighting. Large windows change what is technically visible; they do not automatically change what is actually used.

The third problem is the one that engineers feel most acutely. Software understanding is not a flat list of facts. It is a web of relationships. Why we chose Postgres depends on the constraints we discovered in Redis. Why the billing service is separate depends on a decision made about auth, which in turn depended on a compliance requirement raised by a customer. Any given decision is only fully intelligible in the presence of the ones it descends from. A big window can, in principle, hold all of those facts. But holding them is not the same as knowing which ones are connected to which. Human engineers reason across those connections because they have lived through them. A model reading them for the first time, all at once, does not.

Put together, these three problems explain a pattern that people who work extensively with AI on real codebases will already recognise. Small projects feel effortless. Medium projects feel productive but slightly stubborn. Large, mature projects feel like an endless loop of reintroducing the model to its own environment. The intelligence has not changed. The mismatch between how much the project has become, and how little of it fits — coherently, and in the right proportion — into any single conversation has grown wider.

This is why software development, of all the places to deploy AI, exposes the memory problem most severely. Casual writing has short horizons. General question-answering has no long-term state to preserve. Even domains like customer support or data analysis usually operate over neatly bounded artefacts. Software is different. Software is a body of decisions, extended through time, whose meaning is inseparable from its history. It accumulates. It compounds. And it does so in exactly the dimension — persistent, cross-session understanding — where today's AI systems have the least to offer by default.

The challenge is not that AI lacks intelligence. The challenge is that software projects require a kind of continuous understanding that reaches far beyond a single conversation, or a single window, or a single session. Before we can talk about the shape of a system that provides that understanding, we have to look at the thing it is trying to serve. We have to look at how a software project actually accumulates knowledge over time, and what that accumulated knowledge really is.