I was drafting store replies late one afternoon. The reply was meant for my wallpaper app, and halfway down the paragraph Gemini mentioned a feature name that belongs to a different app of mine — the one for healing sounds — as if it had always been part of the conversation.
I had not typed that app's name anywhere in the prompt. Gemini remembered it anyway.
Opening a fresh chat changed nothing. It took me until the third time before I accepted that the thing being referenced was not the conversation in front of me.
Let me say the important part first: this was not a malfunction. It was the setting behaving exactly as documented. What tripped me up was that the information I thought I had deleted was still arriving through a second route.
The setting doing this is called Memory
Gemini Apps can personalize answers using memory of your past chats. On a computer you'll find it at gemini.google.com, under "Settings & help" at the bottom of the screen, then "Personal Intelligence." Memory sits there as a single toggle.
A few conditions have to line up before it does anything. I went through mine one at a time.
| Item | Condition |
|---|---|
| Age | You need to be 18 or over |
| Account | A personal Google Account. Work, school, and managed accounts are excluded |
| Activity | Saving activity has to be on. With it off, the feature simply doesn't run |
| Where it works | The Gemini mobile app, the web app, Gemini in Chrome, and Gemini on a smartwatch |
| Where it doesn't | Gems and Gemini Live conversations. You can still ask, by typing, for a past Live conversation to be referenced |
One line explained my situation immediately. The bleed only ever happened when I was working in a plain chat. The full requirements are laid out in Get personalization with memory of your past Gemini chats.
I had also assumed personalization arrived through a single door. It doesn't. Gemini Apps personalize from three separate inputs: memory of past chats, content and activity from the Google apps you've connected, and custom instructions that shape how answers come back — in some regions those are labelled saved info. Each one is configured separately, and each one is cleared separately.
That explains a complaint I'd seen and not understood: people clear saved info, nothing improves, and they conclude the setting is broken. Usually only one of the three doors has been closed. I was doing the same thing. Until you work out which input a stray detail is coming from, even the correct action gives you no feedback.
You can also check on the spot. Ask "Did you use information from past chats?" and Gemini will tell you. When I tried it, the answer acknowledged an earlier conversation. A question I had been guessing about for days took one sentence to settle.
Deleting doesn't stick because there are two sources, not one
My first move was to delete the chats that looked responsible. I assumed that was the whole job. It wasn't. Days later the same context surfaced again.
The reason turned out to be simple. What Gemini knows about you can arrive from two directions. One is the past chats themselves. The other is content pulled from your connected apps. Clear only the chats and the same detail flows back in from the apps. Disconnect only the apps and the detail is still sitting in a chat, ready to be read.
Neither half is sufficient on its own. The sequence I follow now:
- Open Gemini Apps Activity and delete every chat that contains the information, then remove it from your recent chats list as well.
- Disconnect the app that supplies that information.
- Wait. After a deletion it can take a while before Gemini stops using the content for personalization, and changes you make inside a connected app can take a few days to show up on the Gemini side.
A word more about waiting, and about the blunt instrument nearby. Because the feature depends on activity saving being on, switching that off stops memory entirely. It works. It also costs you something: the continuity you actually wanted goes with it.
I tried exactly that for a week and turned it back on. The thing I wanted to stop was one specific bleed, while the rest of the carried-over context was doing real work for me. Separating where things live beat switching everything off.
Step three is the one I'd underline. I ran the same test prompt seconds after deleting, decided nothing had changed, and went looking for a problem that didn't exist. The mechanism was fine. My patience was the broken part.
Gems ignoring memory turns out to be useful, not limiting
I read the last row of that table twice. Memory of past chats doesn't apply inside a Gem.
Written as a limitation, it was the answer to my problem. If I don't want two projects mixing, I can do that work somewhere the mixing can't reach.
Here's the split I've settled into.
| Work | Where it lives | Why |
|---|---|---|
| Store copy and review replies for a specific app | A Gem dedicated to that app | The context is pinned in the Gem's instructions, and nothing from another app can wander in |
| Cross-cutting questions and research | A plain chat | These are exactly the cases where I want yesterday's thread carried forward |
| Drafts I'm not ready to show anyone | Memory off, or deleted from activity the same day | Anything I plan to remove later shouldn't sit somewhere it can be read back |
When I set up a Gem, the instructions start with three things only: the app's name, who the copy is for, and the phrases I don't want used. Longer instruction blocks stop getting reread, including by me, so anything beyond those three goes into the prompt itself where I'll actually see it.
Plain chats hold the unfinished thinking. Memory helps there, because I'm not restating last week's decision every time I open a thread. The same feature becomes an obstacle or an assistant depending purely on which room I'm standing in.
Since adopting this, the bleeding has stopped. As a single rule: pinned context goes in a Gem, half-formed thinking goes in a plain chat. When I can't decide, I ask whether I'd want my future self to inherit the thread. If yes, plain chat. If it belongs to this job only, a Gem.
When the setting isn't there, check in order
Personal Intelligence is rolling out gradually. Not seeing it is not, by itself, evidence that anything is wrong.
I confused "absent" with "broken" and spent a while hunting for a fault. Now I check in a fixed order: account type (personal or managed), the state of activity saving, and then availability. If you work primarily from a managed account, that first check will likely end the search on its own.
I've written up the same waiting-versus-broken distinction for a different surface in When a New Gemini Feature Hasn't Reached Your Workspace, Here's How to Tell Waiting From Broken.
What happens to what you send is a separate question
Everything above concerns the consumer app. How data sent through the API is handled is governed by a different set of rules, and conflating the two leaves you worrying about the wrong place.
Separating them was what finally let me relax about it. The API side is covered in What decides whether your Gemini API data trains Google's models, and the one exception on the paid tier.
For the broader picture of what's retained and what you control, the Gemini Apps Privacy Hub is a reasonable starting point.
One thing worth trying today
In whichever chat you use most, ask once: "Did you use information from past chats?" Knowing the answer tells you whether your conversations need splitting up at all.
If the answer is yes and you'd rather it weren't, remember that you have three levers rather than one, and that two of them have to be pulled together for anything sourced from a connected app.
I've made that question the way I open a new piece of work. Finding out what the other side already remembers, before I start talking, has saved me more rewriting than any prompt technique I've tried.
Thank you for reading this far. If you've been puzzled by the same kind of bleed, I hope this saves you the three rounds it took me.