Inspiration
I have been working intensively with AI for several years—not only for experiments, but as a real part of my daily work across software, business, research, planning, writing, and creative projects.
As the models became more capable, the work I did with them became more ambitious. But I kept running into the same fundamental limitation: the conversation itself was temporary.
A long chat could contain hundreds of important decisions, rejected ideas, constraints, technical discoveries, open questions, and unfinished tasks. Eventually, it would become slow, unstable, too large, or simply no longer suitable for continuing the project.
Starting a new chat often meant losing the exact state of the work.
The model might remember the general topic, but not reliably enough to continue a complex project. Important distinctions disappeared:
- Was something actually decided, or only discussed?
- Why had an alternative been rejected?
- Which rules and constraints were still active?
- Which implementation steps had already been completed?
- What was the exact next unfinished task?
- Which actions still required my explicit confirmation?
I repeatedly had to copy large amounts of context, reconstruct previous decisions, and explain things that had already been settled.
The AI could reason well, but the collaboration itself had no durable working memory.
This problem became especially visible during OpenAI Build Week, when a central development conversation became extremely large and unstable shortly before an important project transition.
I did not want another summary that merely described the project. I wanted a new chat to understand the project deeply enough to continue as if it were the same working relationship.
That was when External Brain System became necessary.
What it does
External Brain System, or EBS, moves the durable working state outside the individual conversation.
It captures project knowledge and working state as structured records with:
- stable identities;
- versions;
- relationships;
- provenance;
- lifecycle states;
- authority roles;
- recovery information;
- current focus;
- exact checkpoints;
- next actions.
EBS distinguishes between different kinds of information, including:
- confirmed decisions;
- decision candidates;
- rejected alternatives;
- rules and protected constraints;
- reusable knowledge;
- processes and agents;
- mutable working copies;
- immutable snapshots;
- execution evidence;
- maintenance records;
- append-only logs;
- open tasks.
This distinction matters because not everything that appears in a conversation is equally authoritative.
An idea proposed by an assistant is not automatically a decision. An old statement may have been superseded. A search result may be relevant but not canonical. A summary may omit the reason why something was decided.
Instead of copying an entire raw conversation into a new chat, EBS creates a high-fidelity transition package with two complementary layers.
The first layer is a narrative. It preserves the reasoning path, including:
- the project objective;
- important findings;
- active decisions;
- decision rationale;
- rejected alternatives;
- unresolved questions;
- current focus;
- exact checkpoint;
- immediate next action.
The second layer contains the complete current record state required for safe continuation.
A fresh isolated model receives only this transition package. It must reconstruct the relevant state, identify the exact checkpoint, and continue with the next unfinished task.
Its structured response can then be evaluated against deterministic acceptance criteria.
EBS does not claim to create an infinite physical context window. Instead, it provides functionally unbounded continuity through persistent external state, selective activation, governed reconstruction, and controlled continuation.
How I built it with GPT-5.6 and Codex
I began developing EBS in a regular ChatGPT conversation with GPT-5.6.
At first, I worked almost entirely through natural language, often from my phone. I used Gmail to preserve the decisions, rules, processes, and architectural ideas that emerged from the conversation.
This made it possible to start developing and operating EBS before a dedicated application, database, or interface existed.
Gmail already provided durable primitives that could be mapped to EBS concepts:
- drafts became mutable working copies;
- internally delivered and read-back-validated messages became immutable snapshots, logs, and execution evidence;
- labels became project and record views;
- Gmail search provided retrieval.
This was more than a convenience. It was an early architectural test.
By mapping EBS onto infrastructure that already existed, I could validate the record model, snapshot lifecycle, recovery rules, maintenance processes, and chat-transition workflow in real use before building a custom technical platform.
As the project became more complex, I continued the work in ChatGPT Work with GPT-5.6.
Later, I used GPT-5.6 in Work together with Codex to develop the portable repository version.
Throughout this process, the Gmail-based EBS remained the persistent source of working state across chats.
After important development steps, the relevant decisions, rules, processes, checkpoints, and implementation status were updated in the Gmail EBS. The stored records were then read back and verified before the work continued.
When a conversation became too long, unstable, or unsuitable for further development, I did not need to reconstruct the project from memory.
A new chat could receive a structured transition containing:
- the relevant narrative;
- the current record state;
- the exact checkpoint;
- the next unfinished action.
EBS therefore became part of its own development process.
GPT-5.6 and Codex helped build the portable implementation, while the Gmail-based EBS preserved, updated, and verified the evolving project state across multiple chats.
I defined the product direction, architecture, governance rules, safety boundaries, and acceptance criteria.
GPT-5.6 acted as the semantic and reasoning partner. It helped:
- distinguish confirmed decisions from candidates;
- preserve rationale and rejected alternatives;
- identify protected constraints;
- reconstruct project state in fresh chats;
- continue from exact checkpoints;
- review consistency and recovery boundaries.
Codex helped turn the evolving protocol into the portable technical implementation, including:
- the Python package and command-line interface;
- Markdown and YAML record formats;
- JSON schemas;
- filesystem and SQLite storage adapters;
- record and relationship validation;
- transition-package generation;
- isolated target-chat evaluation;
- ChatGPT export normalization;
- semantic candidate extraction;
- reconciliation boundaries;
- SQLite/FTS5 search;
- automated tests;
- CI and jury workflows;
- executable documentation.
The development process itself became a real-world test of the central EBS promise: complex AI-assisted work can continue across conversations, tools, and execution environments when the durable working state exists outside any single chat.
Challenges I ran into
The hardest challenge was deciding what “memory” actually means.
Storing text is easy. Reliable continuity is much harder.
A retrieval result may be relevant but outdated. A statement from an old conversation may have been superseded. An assistant proposal may never have been approved. A summary may omit the reasoning behind a decision.
Two similar records may be duplicates, supporting evidence, contextual refinements, contradictions, or separate facts.
EBS therefore needed more than embeddings, summaries, or search.
It needed:
- stable identity;
- provenance;
- authority;
- lifecycle state;
- explicit relationships;
- supersession;
- contradiction handling;
- protected semantics;
- confirmation gates;
- recovery checkpoints.
Another major challenge was transition fidelity.
A simple project summary was not enough. The new chat needed both the human reasoning context and the exact current record state.
If either part was missing, a target model could sound convincing while continuing from the wrong checkpoint or silently changing an important decision.
Privacy was also central.
The real Gmail implementation contains private working information and could not simply be published. I therefore created a sanitized 37-record demonstration derived from the real EBS architecture.
The repository excludes:
- raw private chats;
- private Gmail messages;
- personal email addresses;
- mailbox message and thread IDs;
- private business content;
- authentication information;
- private semantic-unit text;
- private generated indexes.
The target-model evaluation also had to be trustworthy.
The isolated target model must not receive the answer key, previous target responses, historical acceptance reports, or private evidence.
Its first unchanged response must be preserved and evaluated separately.
Finally, the jury workflow needed to remain reproducible without requiring access to the private Gmail environment.
That led to a self-contained repository demonstration using sanitized fixtures, deterministic tests, generated transition packages, integrity hashes, and isolated target-model evaluation.
Accomplishments I’m proud of
The achievement I am most proud of is that EBS is not only an idea, a prompt template, or a theoretical memory architecture.
It already worked as an operational system in Gmail before being extracted into the portable repository implementation.
The project demonstrates:
- persistent model-readable working state outside a conversation;
- stable record identities and authority roles;
- mutable working copies and immutable evidence;
- high-fidelity transitions combining narrative and complete record state;
- reconstruction in a genuinely fresh model context;
- continuation from an exact unfinished checkpoint;
- deterministic evaluation of the reconstructed state;
- filesystem and SQLite storage equivalence;
- provider-neutral ChatGPT export import;
- semantic extraction with source-span provenance;
- explicit non-canonical reconciliation boundaries;
- reproducible SQLite/FTS5 search;
- a privacy-safe 37-record demonstration based on the working Gmail implementation;
- a private-scale benchmark involving 5,782 semantic units, represented publicly only through sanitized methodology and aggregate results.
EBS also survived the problem it was created to solve.
Its own development continued across multiple large conversations while preserving important decisions, rules, processes, implementation states, and exact working checkpoints.
One particularly clear example happened during the submission process itself: a long chat produced a plausible but incorrect Codex Session ID. The Gmail-based EBS recovered the authoritative value independently from two persistent records.
The chat hallucinated. EBS remembered.
What I learned
The most important lesson was that AI memory is not primarily a storage problem.
It is a state-governance problem.
A useful external memory system must know more than what was said.
It must also preserve:
- where information came from;
- whether it was confirmed;
- whether it is still current;
- what authority it has;
- what it relates to;
- whether it can be changed;
- what would count as successful continuation;
- where work must resume after interruption.
I also learned that a transition cannot be considered successful simply because a package was generated.
The receiving model must demonstrate that it understood the state and can continue safely from the exact checkpoint.
Another important lesson was that deterministic tools and language models are strongest when they have different responsibilities.
The model handles:
- semantic interpretation;
- contextual reconstruction;
- reasoning;
- continuation.
Deterministic code verifies:
- schemas;
- record coverage;
- identities;
- relationships;
- hashes;
- safety flags;
- acceptance conditions.
Neither layer is sufficient alone.
What’s next for External Brain System
The Build Week version focuses on proving the core protocol, transition model, privacy boundaries, and portable reference implementation.
After the submission, the next phase is productization.
Planned work includes:
- simpler commands for creating and updating records;
- automated snapshots;
- automated maintenance processes;
- append-only execution logs;
- a project and record browser;
- a desktop or web interface;
- additional storage adapters;
- optional Gmail synchronization;
- multi-user permissions and collaboration;
- improved semantic reconciliation;
- packaged installation;
- hosted deployment options;
- support for additional AI providers and local models.
My long-term goal is to make AI-assisted work portable beyond any single conversation, model, provider, or application.
Conversations may end, but the context, decisions, and progress behind the work should remain accessible, verifiable, and transferable.
Log in or sign up for Devpost to join the conversation.