Conversation state and context management

Multi-turn applications must decide which history to retain, summarize, or retrieve. Sending the entire conversation indefinitely increases cost and may exceed the context window; discarding everything can make follow-up questions confusing. Track the request and conversation boundaries, use a deliberate history policy, and distinguish user-provided claims from verified records. Apply access control before adding private history or retrieved documents to a prompt. Avoid sharing one user's state with another session, and define retention and deletion behavior. Summaries are lossy model-generated data, so preserve important facts with provenance and validate them when used for consequential decisions. Conversation history is application data and needs explicit ownership and retention rules. Key state by the authenticated user and conversation, enforce expiration, and prevent client-supplied IDs from selecting another user’s history. For long discussions, keep a bounded recent window and optionally a compact summary, but preserve provenance for facts used in sensitive decisions. Summaries can omit qualifications or introduce errors, so retrieve authoritative records when accuracy matters. Test a new session, expired session, deleted conversation, concurrent requests, and a user switching accounts on the same browser. Implementation drill: trace one representative request through the stages in the diagram. Write down what enters each stage, what output or evidence it produces, and which identity is allowed to perform it. Then test an empty input, an unauthorized request, a dependency timeout, and an unexpected result. For each case, state whether the application should retry, reject, abstain, or ask a person for help. Keep the observed failure as a regression example so changes to prompts, models, data, or code can be checked against the same behavior. Practice task: Why should conversation history be isolated by user or session?