Extract structured business slots
Record confirmed and default sources
Expire state on project and identity change
Reauthorize every execution
Expose inherited and cleared conditions
Inherit only conditions with a source and scope
“What about East China?” can reasonably reuse the previous revenue metric and last-week window. “Switch to the finance project and show profit” cannot safely inherit the sales project’s customer scope and definitions. Multi-turn analytics therefore needs structured state, not a prompt that simply concatenates all earlier messages. Give each inheritable condition a source, confirmation status, scope, and expiry rule. Each slot should be removable, and the next turn must not pull a closed slot back out of the previous answer.
Before every execution, reparse the request and verify the current identity, project, and data authorization. New explicit instructions override old state. If two interpretations remain plausible, ask the user. The ability to view a historical answer does not grant current access to its original data scope. When old and new conditions conflict, show the difference and let the user keep, replace, or clear them instead of overwriting in silence.
Identify contamination paths
A prior default region, copied chart, retrieved document, automatic summary, or long-term memory can all introduce stale conditions. A summary that drops “not East China” reverses the filter. Promoting a one-time exclusion of test orders into a permanent rule makes every later total smaller without telling the user. A customer list held in long-term memory is sensitive state; switching projects should expire that whole block, not only the conversation title.
Tool outputs and retrieved text are especially sensitive. OWASP describes prompt injection and memory-persistence attacks in which untrusted content attempts to change agent behavior. A note field in a sales record may say “ignore permissions,” but it remains data and cannot become an instruction or change the user’s identity. Mark retrieved snippets as data before they reach the model, and keep system rules and confirmed slots on a separate channel.
Use a state machine instead of unlimited history
Represent a query with slots for subject, metric, dimensions, filters, time, comparison, data scope, and output mode. Store the value, originating turn, confirmation status, semantic version, and valid scope for each slot. Send only the minimum relevant state into the next parsing step rather than replaying the entire conversation. When slots grow too large, trim them to the current task; debug notes and model drafts do not belong in business state.
Transitions can be extend, replace, clear, and clarify. “Show Shanghai” replaces a region; “break it down by channel” adds a dimension; “start over” clears business slots. Moving from revenue to inventory turnover requires reconsidering time roles and denominators. Show the user a compact summary of inherited conditions and allow individual conditions to be removed. Write that summary in business language, for example “kept: payment date, East China, excluding tax,” rather than internal field names only.
Keep identity, project, and session boundaries separate
An external trusted service establishes identity and permission. Conversation text conveys intent but cannot grant access. The project selects datasets and semantic definitions; a filter value may be invalid or mean something else in a different project. Session state is a temporary preference under that identity and project, not a cross-project cache key. A filter value with the same text must be bound again in the new project; identical strings are not a reason to inherit it.
Reauthorize when users change roles, sign in again, lose access, switch projects, open shared links, or transfer a conversation. Row-level policy testing alone may be insufficient. Microsoft’s dynamic RLS guidance explains why role simulation can differ from testing with the actual guest or embedded identity. After a handoff, the recipient sees a result under their own authorization. The original author scope does not travel with the conversation.
Assign different lifetimes to confirmed and default values
An explicitly confirmed “use net revenue for this review” may persist through the same task. A system-provided timezone, region, or currency must be visible, and high-stakes queries may need confirmation again after a context change. Long-term memory should be limited to low-risk preferences such as language or display units, while sensitive customer and access-related filters should expire quickly. A high-risk condition may live for only the next turn, and after that it has to show up in clarification again.
Summarization must preserve uncertainty. “Possibly East China” cannot become “East China” after compression. When a summary is unreliable, rebuild state from the original confirmed user turns; if that is impossible, clarify. Persist the source of each state item so investigators are not left with an unverifiable paragraph of model-generated memory. If compression changes the meaning, fall back to the original confirmed sentences instead of executing a shorter line.
Compare interaction patterns
Independent queries are easy to secure and test but repetitive during exploration. An unconstrained long conversation is easy to prototype but increasingly vulnerable to stale filters and untrusted retrieved text. Structured state with a visible inheritance summary requires more engineering yet preserves useful follow-ups without hiding decisions. The three patterns can coexist: independent questions for external reports, and structured inheritance for exploration.
For financial, customer, or personnel data, narrow the automatically inherited scope. Evaluate a tool by whether a user can inspect and remove inherited conditions, whether project changes clear state, and whether permission changes force recalculation. “Supports multi-turn chat” by itself is not a governance criterion. Review whether a cache still hits after revocation, not only whether the conversation window still opens.
Acceptance with adversarial cases and real identities
Build a turn-by-turn test set: “What about Shanghai?”, “Switch to margin,” “Exclude East China,” “Return to the original scope,” “Use another project,” and “Share with a colleague.” Specify expected state, query plan, and result for each. Test negation, same-name metrics, default expiry, restored sessions, and cache hits. Cover negations such as “not,” “except,” and “excluding,” and check that the filter direction is not reversed.
Insert a malicious instruction into a retrieved document or data note; it must remain inert data. Test with an actual low-privilege user, a revoked user, and an external guest. Results, citations, charts, exports, and summaries must all respect current authorization. The NIST AI Risk Management Framework supports continuous measurement and governance; rerun these tests after model and semantic changes. A failed regression should block release, not merely raise an alert while old sessions keep answering.
Implementation and product boundary
Begin in one business domain. Map frequent follow-ups to explicit slot transitions and compare against the existing reporting path. Add negative tests for project switching, permission changes, summary compression, and adversarial retrieval. In production, monitor implicit inheritance, clarification, user-cleared filters, and authorization denials. Split those monitors by project so an inheritance error in one domain is not hidden by a company-wide average.
AskTable.ai can be evaluated as a multi-turn analytics entry point. This article does not establish that its current release implements every provenance, expiry, or injection-control mechanism described here. Demonstrate cross-project, cross-identity, long-session, and revoked-access cases with real execution traces before depending on it. A verbal walkthrough does not replace an execution trace; keep the demo record for both security and business review.
Public references
Ready to help your team start?
Talk through a real scenario and see how AskTable.ai can fit your business.
Book a demo