Understanding Anterograde Amnesia in AI Models

Imagine a model that helped a customer's analyst last week. Today the same customer comes back with a follow-up question. Before reading on, decide for yourself whether the model can build on what happened last week. Your answer determines a failure mode that shapes how AI systems have to be designed around the model.

A session is one bounded stretch of work with the model. Within it, the model answers using the information it is given. When the session ends and a new one begins, the new session starts without the previous one attached. The timeline below traces this boundary, from the first session through to the point where the next one starts.

The diagram makes one point clear. Session 2 begins at the far end of a boundary that erased the conversational context. The model in Session 2 is the same model, but it is not holding Session 1 in view. Whatever the second session needs has to arrive through the input that the system provides.

The key word in the definition is across. Within a single session, the model can work with the information it is given, including earlier turns of that same conversation. The failure appears when a new session begins. Nothing from the previous session is available to the model unless the surrounding system supplies it.

The source names several things the model does not remember once a session ends: previous conversations, rejected phrasings, and corrections made by experts. The comparison below sorts these customer-facing items into what is lost by default and what survives only when the wrapper stores it. The point is not that the model forgets gradually; the point is that the default outcome at a session boundary is loss.

Consider a customer who tells the system their reports should always use metric units. In a second session, the system will only honor that preference if something outside the model holds it and supplies it again. The same logic applies to a correction an expert made to a wrong answer, and to a file the customer uploaded last week. The model itself does not hold any of these forward.

If the model does not keep memory between sessions, the system as a whole can still have memory. The source is direct about where it sits: whatever memory the system has lives in the wrapper, not in the model. The model and the wrapper are separate parts of the system, and the wrapper is the part that can retain information across sessions.

The diagram shows the division of responsibility. The model handles each session it is given. The wrapper is where information from earlier sessions has to be kept so the system can use it later. Anything the customer expects the system to remember must be placed in the wrapper, because the model will not carry it forward on its own.

Because the wrapper holds the system's memory, its design becomes a central concern. The source states that the wrapper is the FDE's responsibility, so the design of the wrapper determines what the system can remember across sessions. Whoever builds the deployment must decide three things: what information is worth keeping, where it is stored, and how it is supplied back to the model when a later session needs it.