Being honest about a bounded window

The failure users hate is not forgetting

Users accept that a system has limits. What they do not accept is being told something is remembered when it is not.

The damaging pattern is specific: an assistant says “I’ll remember that” and stores nothing; or it silently compacts a conversation and then answers as though the dropped material never existed; or it invents a plausible version of a detail it no longer has. In all three the user’s trust breaks not because of the limitation but because the interface lied about it.

So the design rule is narrow and strict: the product may only claim to remember what it actually stores, and it must show what it dropped.

Four things worth surfacing

A context indicator. Something showing how full the window is. A subtle bar, a token count, a “long conversation” marker. Users who can see the constraint work with it (they start a new conversation, or restate the important thing) rather than being surprised by it.

A compaction marker. A visible line in the transcript: “Earlier messages summarised.” With an expand control that shows the summary, and ideally a link to the full history. Users who see it stop being confused about why the assistant’s memory changed character mid-conversation.

The memory list. Everything stored about the user, with source, date and a delete control per item. This is the mechanism from the memory lesson, presented as a feature rather than a compliance page.

The sources used. Which passages, which documents, which memories informed this answer. The selection module argued for this as a correctness mechanism; it is also the thing that lets a user say “you used the wrong document” instead of “it’s wrong”.

Say it in the answer when it matters

Where something has been lost and the answer depends on it, the answer should say so.

I no longer have the earlier part of this conversation in full: I have a summary. It records that you chose the standard plan, but not the discount code you mentioned. Could you repeat that?

This reads as competence rather than weakness, and it is far better than the alternative, which is inventing a discount code that looks right.

It requires the model to know what it does not have, which it cannot do on its own. You have to tell it: one line above the compacted block saying what kind of material was dropped, and an instruction that it may say so.

“Start a new conversation” is real advice

The standard support answer sounds like a fob-off and is actually correct engineering, for reasons this course has established:

• A fresh window has no accumulated errors to be consistent with.
• The task statement is at the top, in the strongest position, instead of buried under forty turns.
• Nothing has been compacted, so nothing has been lost.
• The cost per turn resets to the bottom of the quadratic curve.

So build for it rather than apologising for it. Offer to carry forward a handover note into the new conversation (goal, decisions, artefacts, what failed) so the user gets the clean window without retyping their problem. That is a good feature and it falls straight out of the previous lesson.

Do not over-promise in the system prompt

A small thing with an outsized effect. If your system prompt says “you have full memory of everything the user has told you”, the model will act on that claim, and it will confabulate rather than admit a gap, because the instruction says the gap cannot exist.

Describe the actual arrangement instead:

You have: a summary of earlier turns, the last 6 turns in full, and a list of
stored user preferences. You do not have the full earlier conversation. If you
need something that is not present, ask for it.

That paragraph costs forty tokens and converts a class of confident fabrication into a question. It is one of the highest-return sentences in a system prompt for a long-conversation product.

Measure the honesty, not just the accuracy

Two metrics that most teams do not track and should:

The unsupported-detail rate. On conversations that have been compacted, how often does the answer state a specific value that is not in the retained context? Detectable with the same containment check used for citations: extract ids and numbers from the answer and look for them in the window.

The ask-rate. How often does the assistant ask for something it has lost, rather than guessing? A rate of zero on a system that regularly compacts is not good news; it means it is filling gaps rather than naming them.

Both are computed from artefacts you already have, and both move when your compaction policy changes, which makes them exactly the kind of regression signal the last module of this course is built around.