ThoughtSpot 26.9 turns Spotter’s memory into a governed production feature

ThoughtSpot Cloud 26.9 makes Spotter Memory generally available and enables it by default, moving a central piece of the vendor’s conversational analytics stack from experiment toward normal enterprise operation. The same September release adds a beta that lets users select multiple governed Models in one Spotter conversation. (ThoughtSpot 26.9 release notes)

Memory becomes part of the operating model

Spotter Memory stores two kinds of reusable context. “Rules” capture business definitions and constraints, such as how an organization defines revenue. “Recipes” preserve repeatable analysis workflows, including which columns, filters and formulas to use. Memory can be generated from trusted Liveboards or from corrections and definitions supplied in conversations, and it is applied to later questions on the same data model. (Spotter Memory documentation)

The release also adds a Regenerate option so administrators can refresh learned memory when an underlying Liveboard changes. A renamed Remember this action lets users preview the definitions Spotter will add from an answer. ThoughtSpot says users with the “Can manage Spotter” privilege can manage memory only for Models they can read, while column-level controls continue to be enforced when queries execute. Memory generation and use are limited to Spotter 3. (ThoughtSpot 26.9 release notes; Spotter Memory documentation)

For teams deploying natural-language analytics, the operational implication is important: correcting an answer is no longer necessarily a one-session fix. Definitions and query procedures can become managed artifacts that persist across future questions. But those artifacts also need a maintenance owner, because stale Liveboards or bad corrections can become reusable context; the new regeneration control is the mechanism ThoughtSpot provides for keeping that context aligned. (Spotter Memory documentation; ThoughtSpot 26.9 release notes)

One conversation, multiple models

The multiple-Model beta allows a user to choose, for example, Revenue and Finance Models and ask a question spanning both. A broader cross-model mode can rank available Models, ask for clarification when confidence is ambiguous, query permitted sources and cite the Models used in the resulting answer. ThoughtSpot lists current constraints: combined answers are text summaries rather than integrated charts, English is required, and complex questions can take longer. The beta requires ThoughtSpot support to enable it. (Cross data model search documentation)

The privacy decision is explicit

ThoughtSpot’s version guide says Spotter Classic works primarily from metadata and does not share data values with LLMs by default, while Spotter 3 always shares relevant query results with an LLM to produce deeper analysis. The company says row- and column-level permissions are enforced, only filtered results needed for a question are transmitted, provider models do not retain the data, and customer data is not used to train foundation models. Its separate data-handling guide says LLM-created Python used for advanced analysis is cached in Azure for six hours by default, with persistence affected by saved-conversation settings. (Spotter versions; Spotter 3 data handling)

That makes the upgrade choice concrete: Spotter 3 gains persistent business context and cross-model reasoning, but enterprises must review what filtered query results leave the warehouse, how conversation retention is configured, and who can curate memory before enabling it broadly.