AI Memory vs Project State: What Your Next Chat Needs
You have four months of conversations about this project. You can search them. The assistant remembers things about you. And you still cannot answer the only question that matters this morning: where does the work actually stand?
That gap is not a memory problem. It is a category mistake. Three different things get called memory, and the one everybody talks about is the least useful of them.
Three things people call memory
History is the record of what was said. Every thread, every exchange, searchable and mostly complete. It grows forever and it never tells you which parts still apply.
Memory, in the sense the assistants use it, is a profile built from that history: your preferences, your role, a few facts it inferred. It is a summary, it is partial, and it drifts. What it keeps and why is covered in what AI actually remembers.
Current state is neither. It is a short, deliberately maintained answer to where this work stands right now: the objective, what has been decided, what is blocked, what happens next. Nothing produces it automatically, because it is not a record of anything. It is a judgement, made by you, about what is still true.
The trap is that history and memory both grow on their own, so it feels like the system is keeping track. It is keeping a transcript and a character sketch. Neither is a status.
What a new chat actually needs
Start a fresh conversation and watch what you end up typing. It is almost always the same six things.
What we are trying to achieve. One or two sentences of objective, not background.
Where it stands now. The current version, the current numbers, what is done and what is not.
What has been decided, and why. Including the options that were rejected, which is the part that stops the assistant from cheerfully proposing them again.
What must not change. Constraints, commitments, the client’s one rule.
What is still open. Questions you have not resolved, so the assistant does not answer them by assumption.
The next action. What you are doing in this session, specifically.
Six items, a page at most. Notice that none of them are your conversation history. They are the conclusions drawn from it. When people say they are tired of re-explaining, this is what they are re-explaining, and they are re-deriving it each time from scratch.
Why more history makes it worse
There is a reflex to solve this by giving the assistant everything. More memory, longer threads, the full archive attached. It backfires for three reasons.
Volume crowds out relevance. Everything loaded is competing for attention with the part that matters. One person building with these tools recorded that roughly half of their available context was consumed before the first useful output, purely by loaded background. Whether that is typical is unknown, but the direction is obvious.
Old and current sit side by side with no labels. A decision from March and its reversal in July look identical to a system reading both. Without a marker for what supersedes what, the assistant averages them, and you get an answer that is a blend of two incompatible plans.
Nobody maintains a transcript. A running record is append only, so wrong things stay in it forever. A current state document is short enough that keeping it correct is a two minute job, which is the only reason it stays correct.
Rules, state, history
The useful arrangement is three layers, each with a different job and a different rhythm.
Durable rules change rarely. Who you are, how you work, the standing constraints, the voice. Written once, revisited quarterly. These can be loaded every time, because they are short and they are always relevant.
Current state changes constantly. The six items above, for the piece of work in front of you. Updated at the end of a session rather than the start, while you still remember what happened. This is the layer almost nobody keeps, and the one that removes the most re-explaining.
Searchable history sits underneath, untouched. You do not load it. You go into it when a specific question needs the detail, and then you come back out. It is an archive, not context.
Most assistants give you something for layer one, a partial and invisible version of layer two, and a search box for layer three. How each one handles this is compared in what each assistant keeps.
What not to load by default
Three things belong in the archive rather than the opening of a new chat.
Anything superseded. If a decision was reversed, the reversal is state and the original is history. Carrying both forward guarantees confusion.
Anything from another project. Context from a neighbouring piece of work is the most common source of subtly wrong answers, because it is plausible and invisible, and memory mixing between projects goes through how that happens.
Anything you would not repeat to a new colleague on day one. That is a surprisingly good filter. You would tell them the goal, the decisions, the constraints and the next step. You would not read them four months of messages.
The practical version of this article is one habit. At the end of a working session, spend two minutes writing down where things now stand, and start the next session from that rather than from the archive. Whether you keep it in a file, a document, or a tool that holds it for you is a smaller question than whether it exists at all. If you are weighing which of those to use, which form solves which problem walks through the options, and moving it between assistants by hand is covered in moving context by hand.
AI history keeps growing whether you tend it or not. Project state only exists if somebody writes it.