Quick answerYes, and it should be its own separate setting from opting out of AI handling entirely. A customer can want fast, competent AI-handled conversations while still not wanting the agent to retain personal details, preferences, or conversation history between sessions. Build a distinct memory-off or stateless mode that clears session context after each conversation ends, keep it separate in both the UI and the underlying data model from any standing human-routing preference, and make clear what functionality, like personalized recommendations, the customer is trading away by turning it on.
Two different opt-outs that get conflated
A customer's standing always-route-me-to-a-human preference is about who handles the conversation. What is described here is about what the AI agent is allowed to retain about the customer once it does handle the conversation. A customer can want both, neither, or just one: some people are perfectly comfortable with an AI agent as long as it treats every conversation like the first one, with no memory of past purchases, complaints, or stated preferences carried forward. Bundling that preference into the human-routing toggle, or worse, not offering it at all, forces a customer who only objects to being remembered into either accepting full personalization or abandoning the AI channel entirely.
What memory-off mode actually needs to do
A real stateless mode is more than hiding a memory summary from the transcript. It needs to actually not retrieve, store, or reference prior conversation data when building the agent's context for a new session, the same way building or buying an AI agent's memory and personalization layer has to design retrieval and storage as connected systems. A setting that merely suppresses personalization language in the response while the underlying retrieval still pulls the customer's history is not honoring the opt-out, it is hiding the fact that it is not being honored.
Setting honest expectations about the tradeoff
Turning off memory has real functional costs: the agent will re-ask questions it would otherwise remember the answer to, personalized recommendations disappear, and a customer who has to repeat context every session may find that more frustrating than the personalization they opted out of. Be explicit about this tradeoff when the customer enables the setting rather than presenting it as a free privacy upgrade with no functional cost, so the choice is genuinely informed.
How this interacts with a customer's full data export or deletion request
Memory-off is a forward-looking setting, it stops new retention going forward, it is not the same as a customer's request to export or delete everything the agent already remembers about them. Offer both as distinct, clearly labeled actions: one stops the agent from learning more, the other addresses what it has already learned. Conflating the two into a single button either fails to actually delete existing history when the customer only meant to stop future retention, or deletes more than the customer intended when they only wanted the forward-looking setting.
FAQ
Does memory-off mode need to be a paid-tier restriction or should it be available to everyone? Treat it as a privacy control, not a feature gate. Restricting privacy settings by pricing tier creates its own compliance and trust problems separate from the personalization question itself.
What happens to in-progress context, like an open support ticket, when a customer turns memory off mid-relationship? Scope the setting to future sessions rather than retroactively wiping an active, unresolved case, and be explicit in the UI about what it does and does not affect.
Can a customer be gaming the opt-out to make each conversation look like a first contact and avoid pattern detection? It is worth monitoring for that pattern separately from the privacy feature itself, but the existence of a small number of bad-faith users is not a reason to withhold a legitimate privacy control from everyone else.