Context Engineering · Principal
A user switches accounts. Why does the agent remember the previous customer's preference?
The question
Interview question
A support worker can switch between customer accounts in one browser session. While handling account B, the assistant says, “You usually want invoices sent to the London office,” a preference learned while handling account A. The tool queries for B were authorized. The memory lookup used the same conversation ID across the switch. What boundary failed, and how would you repair past as well as future runs?
Take a few minutes to form your approach. Then open a worked answer and compare the decisions.
Reveal a worked answer
This is not just a bad answer. The context assembly let a fact from A enter a task for B. Once it is in the prompt, a perfectly functioning model can repeat it or use it to choose an action. Authorization on the later invoice tool call does not clean private context already supplied to the model. We need a memory scope that follows the actual subject and tenant, not merely a convenient browser tab or conversation ID.
I would reconstruct the transition: authenticated worker, active customer account, conversation and run IDs, retrieved memory entry, its source, creation time, consent or retention basis, and the exact prompt sent after the switch. Did the memory store key only on user or conversation? Did the browser reuse the prior conversation state? Did a summary or model-side cache contain A's preference even after the memory database query switched to B? A scoped lookup that returns no A record can still fail if an earlier summary already copied the text into the ongoing context.
The design needs an explicit identity tuple for each memory fact: owner or subject, tenant, scope, source revision and allowed uses. At context assembly, bind the run to the authenticated worker and the active account as separate principals, then select only memory permitted for that pair and purpose. On account switch, start a new context epoch. Drop or rebuild conversation summaries, cached prefixes and queued tool results that could contain the prior account's data. Keep neutral workflow state only if it is truly account independent. Check access again at any external action, because the worker's account authorization can change while a long run is paused. OWASP's session guidance describes the importance of maintaining the authenticated session boundary. The account and memory scoping here are application design decisions that sit on top of it.
For containment, disable cross-account memory injection, identify which runs received A facts while operating on B, and inspect any generated messages or actions for disclosure. Remove contaminated summaries and derived memory, not just the original record. If an invoice destination from A was used to send B's invoice, reconcile the actual external action and follow the incident process. A fresh answer saying “sorry” does not undo an email already sent. Keep an audit trail of evidence handles and actions without copying private content into yet another unrestricted log.
The interviewer might say both accounts belong to the same company. That does not make every contact preference interchangeable. The scope can be organization-wide when the source and policy explicitly say so, but an account-specific address must not be promoted because the browser session is shared. The user corrected the agent's memory. Why does the old fact return next week? covers a corrected fact returning later. This case asks whether a fact was ever eligible for the current subject. The safe default is to require a positive scope match before a memory fact reaches the prompt.
Continue reading
Related questions
Read beyond the question
Explore more context engineering
Follow another question in this area, or search the complete Question Library.
Browse this area →Browse Question Library →