5 min read
By

Dreaming V3: ChatGPT gets a memory that rewrites itself — and the delete button doesn't delete everything

6 June 2026. On 4 June, OpenAI began rolling out Dreaming V3 — a new memory architecture for ChatGPT that replaces the manually curated memory list with a background process that autonomously synthesises and updates memories from the entire chat history. What arrives looking like a convenience update is, architecturally, the shift from stored facts to derived state. And that is exactly where the data-protection question begins — one that no toggle answers.

What happened

On 4 June, OpenAI enabled Dreaming V3 for Plus and Pro subscribers in the United States; Free, Go, and international users will follow in the coming weeks. The previous two-layer model — an explicit list of saved facts plus a background reference to chat history — is replaced by a single asynchronous synthesis process that builds memories across many conversations, automatically captures context, and updates existing entries: “You're travelling to Singapore in July” becomes, after the trip, “You went to Singapore in July 2026” — with no user action. The free-tier rollout is enabled by a roughly fivefold reduction in serving costs. OpenAI's internal quality metrics have not been independently verified.

Why it matters

The core of the story is not better recall, but where the memory lives. The synthesised memory is not stored in the conversation log; it sits in a separate data layer that is injected into the system prompt at inference time. Two things follow. First, an audit gap: deleting a conversation does not remove the memories derived from it — and by OpenAI's own admission, the new memory summary does not necessarily show everything the system has retained. Second, an attack surface: Tenable documented back in November 2025 that memories appended to the system prompt can be written to via prompt injection from third-party sources, creating an exfiltration channel that persists across sessions. Whether Dreaming V3 addresses this surface, OpenAI has not said.

What it means for the mid-market

A system that autonomously derives a continuously updated personal profile from years of conversations is, in data-protection terms, profiling — with everything that entails: legal basis, transparency, the right to erasure. Deletion is where it gets concrete: a deleted chat does not take the derived memory with it; complete removal requires deleting both the memory entry and the source conversation, and even then OpenAI retains logs for up to 30 days. How an access or erasure request under Articles 15 and 17 GDPR is enforced against a data layer whose own summary is incomplete is a question you should put to your data protection officer — before a supervisory authority does.

More relevant in practice is everyday use: in many companies, employees work with private ChatGPT accounts. Dreaming V3 now carries context across conversation boundaries automatically — the client project from March flows uninvited into the chat in June. The controls exist, but they are fragmented: the memory switch and the training consent are separate settings, and Temporary Chat is the only hard boundary. Processing happens in the United States — the third-country finding stands. And on 2 August 2026, the EU AI Act's transparency obligations take effect; a memory layer that cannot guarantee its own completeness then becomes a vendor question, too.

What it means for technical development

Architecturally, Dreaming V3 normalises a layer that is currently emerging everywhere in the agent stack: persistent, derived state outside the conversation context, injected at inference time. The shift from “the user curates a list” to “a background process writes the profile itself” is the same move agent frameworks are making with memory stores and vector databases — only now as the default for hundreds of millions of accounts.

For your own architecture, this yields a design requirement that OpenAI is currently demonstrating by failing it: a memory layer needs the same discipline as a tool call. Writes to memory are privileged operations — they need provenance (where does the entry come from?), auditability (what does it actually say?), and deletion semantics that link derived state to its source. Anyone building agents with long-term memory should treat the memory store as a separate, inspectable system — not as a side effect of the model.

Concrete recommendation

In this order. First, establish who in your organisation uses ChatGPT with which accounts — private consumer accounts with memory enabled are, as of now, the wrong tier for business contexts. Second, where ChatGPT remains in business use, move to Team or Enterprise agreements and set memory and training settings centrally instead of leaving them to each individual. Third, establish Temporary Chat as a binding working rule for sensitive one-off questions. Fourth, work with your data protection officer to determine how access and erasure can be enforced against a derived memory layer — and measure your own agent roadmap against the question of whether its memory store is auditable.

This article reflects our technical and strategic assessment. It is not a substitute for legal advice or a data protection impact assessment.

Sources

About the author

KH

Kim Hartwig

CEO · Moselwal Digitalagentur

Kim is responsible for day-to-day operations and provides strategic support to our clients on a daily basis. Her expertise in computational linguistics combines an understanding of communication with technical know-how.