Why does AI forget what I told it earlier?
An AI drops something you told it for one of three different reasons, and they lead to three different fixes: the detail is still in the conversation but has been pushed out of the context window, the detail was written into a long-term memory store but was not retrieved for this particular question, or it was never written into memory at all. The context window cannot be taught to remember — it is a fixed-size buffer that discards the oldest content once it fills — so anything that has to survive into a new conversation has to live in a separate, persistent memory layer, and "my memory is not working" is almost always one of the other two branches. One test separates them in a single pass: start a fresh conversation, then ask for a detail you gave last time and have not repeated today. If it comes back, the memory layer stored it and retrieval is working; if it does not, ask the tool to list what it has stored on that topic and where each item came from — an item that sits on the list but never surfaces in answers is a retrieval problem, and an empty list is a storage problem. Repeating yourself until it sticks cannot tell these apart, which is why the most common advice sends people to the wrong fix.
AI memory systems are structured this way for core efficiency and performance reasons. The short-term context window is a dynamic, token-limited buffer optimized for real-time processing: it holds only the most recent interaction data to ensure responses are coherent and contextually tied to the current conversation. Once the window reaches its predefined token limit, older inputs are automatically discarded, as retaining them would increase computational load and latency for immediate replies. The long-term memory layer, by contrast, is a persistent storage system that requires intentional encoding—AI tools must parse, organize, and tag information to store it for future use, rather than keeping it in the immediate buffer. This split avoids the inefficiency of merging both into one system: a universal buffer would become bloated, slowing responses and raising costs, while separating the layers allows each to serve its purpose effectively. The split also adds a step that is easy to overlook: because the store is not the window, something kept in the store has to be fetched back into the window before it can affect an answer. That fetch is a search, and searches miss. So an AI can fail to use what you told it in three ways, not two — the window is full (temporary loss inside one session), the item is in the store but was not fetched for this question (present but unused), or it was never written to the store at all (nothing to fetch).
Run these checks in order. Each one rules out a branch instead of guessing, and none of them depends on how the tool is built inside. First, separate the session from the store. Close the thread where the lapse happened, open a clean one, and ask about something you established days ago without restating it now. A correct answer here clears both storage and retrieval for that fact, which leaves window pressure inside the long thread as the explanation. Second, if it does not come back, ask the tool directly what it has stored on that topic and where each item came from. An item that appears on that list but never shows up in answers was stored and not retrieved; an empty list means it was never stored, and repeating yourself will not change that, because repetition only refills the current window. If the tool cannot show you its stored list at all, that is itself an answer about how much you can rely on it — you are being asked to take retention on trust. Third, check where you asked: memory attached to one project, workspace or space does not travel to another, so a fact that works in one place and vanishes in another is a scope question, not a storage failure. Fourth, check whether the answer is stale rather than absent: if a corrected fact keeps reverting to its old version, two entries exist and the wrong one is winning retrieval, which is again not forgetting. Do not use the old rule of thumb that says re-sharing a detail several times without effect proves it was never stored. Re-sharing puts the detail back into the window, so what it tests is the window, not the store, and a passing result proves nothing about what was written down.
The context window’s token limit is a fixed constraint that directly leads to temporary forgetting when it is exceeded. Tokens represent individual words or small chunks of text, so even a single long interaction, like a multi-point request or a lengthy explanation, can quickly fill the window, pushing older inputs out of active memory for the current session. This is a deliberate design choice to keep processing fast, as a larger active memory would require more computational power and slower response times, which would harm real-time usability. When the window is full, the AI cannot access prior details in real time, even if those details are critical to the current task—like a character’s backstory in a creative writing project or a key requirement in a technical discussion. Common approaches to this issue include sliding window adjustments, where older segments are shifted out gradually, or selective truncation of less relevant content. However, truncation risks removing nuanced or contextually important information, while sliding windows may still push out details that the user expects to remain accessible.
Long-term memory encoding is not automatic, so many details are never saved beyond the immediate session. For an AI to store information long-term, it must parse the input, organize it into structured data, tag it for retrieval, and confirm that it is worth keeping—steps that require intentional processing. If the input is ambiguous, inconsistent, or lacks clear relevance to a broader context, the AI may skip encoding it to avoid cluttering persistent storage. This is a trade-off between storage efficiency and completeness: storing every detail would bloat long-term memory, making retrieval slower, while skipping ambiguous details reduces the chance of irrelevant or incorrect information being used later. Users often read this encoding failure as forgetting, and then reach for the wrong evidence: the detail does not come back even after being repeated, which feels conclusive but is not, because a stored item that is never retrieved behaves exactly the same way. Only the stored list distinguishes them.
The branch missing from most explanations is the one where the item exists and still does not reach the answer. Storing is not the same as using: at each turn, a small subset of the store has to be selected and pulled back into the window, and that selection is a search over entries, not a lookup of everything you ever said. So an entry can sit in the store, correct and intact, and lose every time. The usual reasons are mundane. The entry is scoped to a different project, workspace or persona, so it was never a candidate for this conversation in the first place. The wording of your question does not match the wording of the entry closely enough for the search to surface it — you saved a preference about travel, and today you asked about a trip. A newer entry has superseded the older one, so the older one no longer takes part in recall even though it remains readable. Or too many entries compete for a limited number of slots and the ones that win are not the ones you needed. This layer also explains why the intuitive fix backfires: pulling in more memories per turn does not straightforwardly help, because irrelevant memories crowd the window and pull answers toward things you did not ask about. The trade-off is real in both directions, which is why the honest position is that the stored list has to be inspectable — not that retrieval can be tuned until it never misses.
Complaints about AI memory tend to arrive as one of a handful of sentences, and each one points at a different branch. “It forgot something I said twenty minutes ago in this same thread” is window pressure: long threads push their own beginnings out, and the fix is to shorten the working thread or restate only the part that still matters, not to change tools. “My memory is not working — it knows me in general but not here” is usually scope: a store attached to one project or workspace is not a candidate for retrieval in another, and the detail is intact where you left it. “I told it once and it has never come up again, even in a fresh chat” splits in two, and only the stored list tells you which: on the list means retrieval never selected it, absent from the list means it was never written. “I corrected it and the old version keeps coming back” is a retrieval conflict between two live entries, not amnesia. “It only remembers when I mention the topic first” is the ordinary shape of query-triggered retrieval: nothing is broken, but nothing is proactive either, and that limitation is worth knowing before you rely on it. Naming the branch first is what keeps you from spending a week on a fix aimed at a cause you do not have.
How do I make an AI remember previous conversations?
Start by discarding the fix most people try first: a bigger context window. A longer window holds more text within one session; it creates nothing that survives the session, so the moment you open a new conversation you are back where you started. It does not reliably improve recall either — more text in the window means more material competing for attention, and the one relevant line becomes easier to lose among near-misses, not harder. Treat window size as a limit on how much you can work with at once, not as a memory feature. Three approaches actually work, and each has a cost you should pick on purpose rather than discover later. The first is to re-brief: keep a short standing brief of the facts that must not drift, and paste it at the top of each new session. It works in any tool and costs nothing, but you pay it every single time, it goes stale as your situation changes, and it occupies window space the task itself needs. The second is to use the tool’s persistent memory layer. It genuinely survives sessions, but only for the part that was really written into it, which is why the ability to open the stored list is the whole value — a memory feature you cannot inspect is a promise, not a mechanism. The third is to keep the facts yourself in a plain file and paste the relevant section per task. It is durable, portable and locks you into nothing, and it is entirely manual, so it decays the week you get busy.
Then change one habit, whichever approach you chose. When a fact has to survive into next month, do not only say it — say it, and then verify in a fresh session that it landed, because the write is the step that silently fails. Give one thread one task, so unrelated material is not occupying the window your current work needs. And write facts in the form you will later ask about them: an entry phrased the way you actually talk about the subject is more likely to be matched than a tidy summary that uses words you never use. Finally, one criterion to carry to any product you evaluate: a memory layer earns trust not by remembering, but by being inspectable. Can you open each entry and see where it came from, when it was written, how confident the system is in it, and what scope it belongs to — and can you correct it on the spot? Remembered it and remembered it correctly are two different claims, and only the second one can be checked.
The same three branches apply to our own digital twin, so here is what you can actually check in it rather than take on trust. Long-term memory is a list of individual entries, not one opaque summary. Every entry carries four pieces of metadata — its source, the time it was written, a confidence value, and its scope — and you can open any entry to read those fields, correct it, freeze it, restore it, or forget it, one at a time. That list is what turns the retrieval branch from a guess into an observation: if a fact is on the list and still does not appear in an answer, you are looking at retrieval, not storage, and you can see that for yourself instead of inferring it from repeated attempts.
Two limits are worth stating plainly, and they are not the same kind of limit. The first is a deliberate design choice. The second is simply a layer we have not built. First, entries come from what you said or confirmed in conversation — the source line on an entry reads, literally, that you just confirmed it. The twin does not go out and gather your files, bills, screenshots or other apps to assemble that list; nothing lands in memory that you did not put there by talking. That makes the list smaller than an automatic one would be, and it also means every line on it came from a moment you were present for. Second, there is no retention period or expiry date that you set yourself; we have not built that layer. What exists is supersession: when a newer entry replaces an older one, the older one stops taking part in recall that same day and stays in the archive, where you can still read it. So an entry can be inactive without being gone, and you can tell which is which by looking.
More on the product in the English overview.
The public primary material this page is built on. We do not restate their conclusions as our own evidence — they are listed so you can check for yourself.