What the model remembers between turns
Nothing carries between turns. Not partially, not approximately — the model retains nothing at all between one request and the next, and every appearance of continuity in your product is something your code did.
Stated that baldly it sounds obvious. It stops being obvious the moment you have to decide what to carry, because there are four structural options, they all lose information, and they lose it in different directions.
The four options and their loss profiles
A window of recent turns. Include the last N messages, drop the rest. Exact within the window, and absolutely nothing outside it. The loss is a hard edge: no gradient, no partial recall, and the transition is invisible from inside the model — a fact from before the edge is indistinguishable from a fact never mentioned. Cheap to implement, predictable to cost, and useless for anything resembling a long-running relationship.
A running summary. Condense older turns into prose that gets carried forward instead of the originals. Reach becomes effectively unbounded. The loss is specifics: names, numbers, exact wording, and anything that looked unimportant when the summary was written. And because summaries get rebuilt from summaries, the loss compounds — generationally, and worst for the oldest history, which is precisely the history a long relationship is made of.
Extracted facts. Watch the conversation, decide what is worth keeping, write it to a structured store, include the store. Durable and cheap for what got captured; completely blind to what did not. The loss is whatever the extractor did not think to keep, which makes extraction quality the whole ballgame. This is the option that produces the most jarring artifacts in production: five oddly specific things known forever, and a fact repeated three times last week absent entirely.
Search over past turns. At each turn, find related earlier material and include what surfaces. Reach across everything, and dependent on the match. The loss is whatever the current turn does not resemble — a topic raised in different words than last time may not surface, and as history grows the competition for the space grows with it.
Most production systems combine two or three, which is why the observed behaviour looks arbitrary. It is several mechanisms with different edges, overlapping.
The proportion problem underneath all of them
Whatever you carry has to share the input with the character definition, and that share is not fixed.
Early in a conversation, the definition is most of the input and the character is strongly expressed. As history accumulates, the definition stays the same size while everything else grows. The character definition becomes a shrinking fraction of the input, and it is competing with text that includes the model’s own recent output.
That is the arithmetic behind drift, and it is why continuity mechanisms and consistency are not separate concerns: every mechanism that carries more history also dilutes the definition. You are always trading one against the other, and a post that recommends more memory without saying that is selling you something.
The turn
THE TURN — what carries
· Nothing, by default
→ continuity is entirely your code's
doing. The model retains nothing between
requests.
· A recent-turn window
→ exact inside, absent outside. Hard edge,
no gradient.
· A running summary
→ keeps gist, loses specifics, and decays
generationally — oldest history worst.
· Extracted facts
→ durable for what was captured, blind to
what wasn't. Extraction quality is the
whole ballgame.
· Search over history
→ reaches everything it can match, misses
what the current turn doesn't resemble.
· Every carried token
→ PAID EVERY TURN, and the bill grows with
the relationship. More memory is a
permanent increase in per-message cost.
· Carrying more history
→ dilutes the character definition. Memory
and consistency trade against each
other.
Choosing by failure, not by capability
The useful way to pick is not “which remembers most”. All four remember a lot. It is which failure you can live with, because you will get one.
If the product’s value is in the recent conversation being sharp, a window’s hard edge is acceptable and its predictability is a real asset — cost is bounded and behaviour is easy to reason about.
If the product’s value is in a long relationship, extraction handles the small set of facts that must never be lost, and a summary handles continuity of texture. The pairing is common because the failure modes are complementary: extraction is precise and narrow, summarisation is broad and vague.
If users return to old topics in new words, search earns its complexity. If they mostly continue where they left off, it does not.
What does not work is expecting any of them to be lossless, or layering all four in the hope that the gaps do not line up. They do line up, they cost more every turn, and the diluted definition drifts faster.
Detection
You can identify which mechanism is failing from the shape of the complaint, and you can do it in aggregate rather than by reading transcripts.
Distance to failure. Log the conversational distance between a fact being stated and being needed again. If failures cluster at a consistent distance, you are seeing a window edge. If they scatter with distance but concentrate on certain kinds of fact, it is extraction.
Specific versus general. Failures on names, numbers and exact wording, while the gist survives, is a summary. Failures on whole topics is a window or a search miss.
Repetition survival. Track facts stated more than once. A mechanism where repetition helps is extraction or summarisation; one where it does not is a window.
Definition share. Instrument the proportion of each input that is character definition. Watching that ratio fall across a long conversation is the single most useful number in this whole subject, and it is the direct measure of drift pressure.
What this costs and what it doesn’t fix
Every mechanism here is a permanent addition to per-turn cost, and the ones with the best reach are the ones that grow. That is the part most easily underestimated at prototype scale, where history is short and the bill is small — the economics look different at two hundred turns.
And none of it fixes consistency. Perfect recall of everything the user said would still leave a character definition competing with a growing pile of conversation for a share of the input. Memory and coherence are separate problems that pull in opposite directions, and any design here is a position on that trade rather than a solution to it.