OpenAI Dreaming: AI is moving beyond the context window

OpenAI Dreaming makes an important shift explicit: useful AI cannot depend forever on whatever fits inside the current context window.

A context window is working memory. It lets a model reason over the current conversation, attached material, retrieved sources, and tool results. It can be very large and still disappear as a coherent working set when the session ends. Long-running collaboration needs another layer that can decide what remains useful later.

OpenAI calls that background process dreaming. Its June 2026 explanation describes a system that synthesises memory from chat history, updates it as circumstances change, and makes a summary available for review. This is more ambitious than saving a few user-requested facts. It is an attempt to preserve continuity across many conversations without copying every old chat into every new prompt.

For operator-builders, the interesting question is not whether an assistant can remember more. It is how adaptive AI memory should work alongside a durable project history that the operator owns.

How OpenAI Dreaming moves beyond saved memories

ChatGPT memory began with explicit or inferred details saved during conversation. OpenAI later added the ability to reference chat history. The current architecture uses dreaming to synthesise a fresher memory state across those interactions.

That distinction matters:

OpenAI says the new memory summary is reviewable and can be corrected through conversation. Its broader memory controls also distinguish saved memories from chat-history reference and provide settings to disable memory or use Temporary Chat.

Those controls point toward the right design principle: persistent memory should be visible enough to inspect, correct, and deliberately exclude.

Memory is not an authoritative project record

An automatically synthesised memory is valuable because it filters. That is also why it should not silently become the authority for consequential work.

An assistant may remember that a project prefers a particular architecture. It may not preserve:

• the exact decision and alternatives considered
• the code version that implemented it
• the tests that passed at the time
• the later commit that superseded it
• the task, report, or human approval behind the change
• whether the remembered preference still applies to this repository

The memory can help retrieve the question. It should not invent the answer when the owned evidence disagrees.

This is the same distinction between a helpful colleague's recollection and a version-controlled engineering history. Both improve continuity. Only one gives the operator a diff, author, timestamp, review trail, rollback point, and exact implementation.

What this means for SwarmCraft

SwarmCraft already has a simpler form of durable software memory: the operator owns the source-code repository.

That repository can preserve:

• application code and infrastructure
• project plans and implementation tasks
• agent skills and repository instructions
• architecture and operating decisions
• scenario inputs, reports, and test evidence
• documentation explaining the current system
• Git history showing how and why the project changed

This is not model memory. It does not automatically infer which past decision is relevant to a new conversation. Its strength is different: it is explicit, portable, inspectable, reversible, and owned by the operator rather than locked inside one assistant account.

The repository becomes the long-term memory of the software because it holds both the implementation and the accepted intent around it. A future agent can inspect the current tree, trace earlier commits, load relevant skills, compare a request with tests, and propose a change without depending on one provider's private recollection of the project.

The best result combines adaptive and owned memory

The productive architecture is not ChatGPT memory or Git history. It is a controlled relationship between them.

1. Agent memory notices recurring goals, preferences, unfinished work, and useful context.
2. Retrieval identifies the relevant repository files, tasks, decisions, and history.
3. Skills explain how this repository expects the task to be performed.
4. The agent proposes or implements a bounded change.
5. Tests, checks, diffs, and human review evaluate the result.
6. A commit records what the operator accepted.
7. Future memory can use that accepted history rather than treating a past conversation as final truth.

That loop can improve both productivity and quality. The assistant spends less time rebuilding conversational context, while the operator retains a durable account of what actually changed.

What an operator should keep reviewable

Before persistent memory participates in a software workflow, decide:

• what the assistant may remember automatically
• what must be explicitly committed to the repository
• what belongs in a private provider memory rather than shared project history
• what should never be retained
• how stale or contradictory memories are corrected
• whether a memory can trigger retrieval but not an action
• which repository evidence wins when memory and code disagree
• who approves changes to skills, instructions, architecture, and production behaviour

The goal is not perfect recall. It is useful continuity without surrendering project ownership.

From agent skills to persistent context

AI agent skills preserve a reusable way of doing work. OpenAI Dreaming points at the complementary layer: carrying useful context about the person and their ongoing work between sessions.

The next article looks at Claude memory and context between sessions. The full series will then examine Microsoft Copilot memory, AWS episodic memory, and the operating boundary between memory, skills, context, repositories, and systems of record.

For SwarmCraft, the thesis is straightforward: let frontier models improve adaptive recall, but keep the software's accepted memory in assets the operator can inspect, version, move, and own.