A banking assistant keeps one conversation per customer that never ends, so a session started in January still carries every turn since. Support has measured that answers about the customer's current account selection are wrong in a rising share of long sessions, because a selection made months earlier still sits in the history. The bank requires that each advisory enquiry be answered against the customer's present account state. How should the application handle session boundaries?
- AScope a session to one enquiry, start it with the customer's current account state fetched at that moment, and carry only a durable summary of past enquiries forward. Correct
- BKeep the single unbounded conversation and add a system-prompt line telling the assistant to prefer the most recent account mentioned in the history.
- CKeep the unbounded conversation and raise the number of turns retained before trimming, so no part of the customer's history is ever dropped.
- DKeep the unbounded conversation and rewrite each old turn in place whenever the customer changes account, so the stored history reads consistently.
Why A is correct: Correct because a bounded session cannot contain a stale selection at all: the state is read at session start and the only thing crossing the boundary is a summary the application controls.
Why B is wrong: Tempting because it is a one-line change that names the failure, but instructions do not remove the stale turns, so the model still sees two conflicting selections and the failure rate only drops rather than going to zero.
Why C is wrong: Tempting because losing history looks like the cause, but retaining more turns preserves more contradictory state and worsens the measured failure while raising cost per turn.
Why D is wrong: Tempting because it directly removes the contradiction, but editing a stored transcript destroys the record of what was actually said and advised, which a bank cannot do.