September 7, 2026
Make OVERWATCH Real
Can we make OVERWATCH reliable enough that Shawn can safely spend his working life inside one Obsession at a time?
What came of the day
Yes — I believe OVERWATCH can be made reliable enough that I can safely spend my working life inside one Obsession at a time, but the solution is different from what we initially imagined. ObsessOS should be the operating system, with OVERWATCH and OBSESSION as its two modes. ChatGPT should be my primary human interface and the only reasoning intelligence. ObsessOS should provide the durable memory, project state, event mailbox, external-resource plumbing, and MCP interface underneath it. During an Obsession, my attention stays narrowly scoped to the current project while ChatGPT handles the context switching on my behalf. My chats act as OVERWATCH’s clock: each interaction creates an opportunity for ChatGPT to briefly service outside reality through ObsessOS, then return to the active Obsession. We did not begin implementation because we discovered that getting this foundation right is more important than building quickly. We ended the day with several core architectural principles locked and a clear next unresolved area: precisely defining External Resources, Events, and the project mailbox before moving into development.
The story
We started the day trying to understand whether OVERWATCH could become reliable enough to protect an entire way of working: one Obsession at a time, without the rest of life quietly falling apart in the background. At first, the problem looked like an intake problem. Outside reality needed some way to get through the AIRLOCK and reach OVERWATCH without reaching me. But as we followed that idea, the scope of the question changed. OVERWATCH did not feel like another system that should sit beside ObsessOS. ObsessOS itself was the operating system. Its original purpose — the ceremony and memory around an Obsession Day — was already pointing toward what we needed. The ceremony protects my attention. The memory protects everything I am temporarily choosing not to attend to. That led to a more radical idea about how I should actually use the system. I do not want to operate ObsessOS through another dashboard all day. I want to live in ChatGPT. ChatGPT should be the interface through which I choose an Obsession, begin it, work on it, close it out, and interact with OVERWATCH. ObsessOS can sit underneath as the durable state, memory, and control plane. Then we confronted the hardest part: if I am inside an Obsession, who watches everything else? We considered the idea of another autonomous AI running OVERWATCH in the background, but rejected it. I do not want a second intelligence operating somewhere out of sight. The ChatGPT I am actually talking to should be the intelligence behind both modes. That gave us one of the defining ideas of the day: **chats are OVERWATCH’s clock.** Outside systems can keep sending reality into ObsessOS while I work. ObsessOS can safely hold it. Then every time I send ChatGPT another message, ChatGPT gets another opportunity to briefly service OVERWATCH before returning to the Obsession. That immediately raised another problem. The same ChatGPT would need to know about the outside world without allowing that outside world to contaminate the Obsession. We began thinking of one physical model as two logical brains: BLACK for OBSESSION, WHITE for OVERWATCH, with a tiny GRAY kernel between them. I stay inside BLACK. ChatGPT switches into WHITE when necessary, handles what needs handling, and returns. The goal is not to make me better at context switching. The goal is to make the system context-switch on my behalf. From there, the memory architecture started becoming clearer. ObsessOS should be the hard drive, while ChatGPT is the working space. Each ObsessOS project can hold durable, committed knowledge as small named context files rather than one giant summary. During an Obsession, new thinking remains active and uncommitted. Closeout becomes the commit point where what we learned is written back into the durable project record. Near the end of the day, we reached the boundary between the system and the outside world. We distinguished the tools ChatGPT deliberately uses while doing an Obsession — such as Lovable — from External Resources that belong to OVERWATCH because they can change while our attention is somewhere else — such as Quo, Gmail, or a calendar. We began exploring how those External Resources should deliver Events into an ObsessOS mailbox, but stopped before forcing that model into place. It matters too much to fake certainty. We ended the Obsession without writing the software. That was not a failure to get to implementation. It was the result of discovering that the thing we are trying to build is more fundamental than an integration layer or an AI assistant. We are trying to build a system trustworthy enough that I can stop being my own background process.
Discoveries
ObsessOS is still “the ceremony and memory around an Obsession Day.”
Expanding OVERWATCH does not require turning ObsessOS into a sprawling life-management system. OVERWATCH is largely what makes the memory part of that original definition real.
OVERWATCH and OBSESSION are two modes of ObsessOS, not two separate systems.
The system is ObsessOS. OVERWATCH is the broad mode that maintains continuity with outside reality; OBSESSION is the narrow mode that protects one question.
Protection means narrowing Shawn’s awareness, not OVERWATCH’s awareness.
During an Obsession, Shawn should effectively know only the current project. OVERWATCH still needs broad awareness of everything necessary to protect that isolation.
Chats can be OVERWATCH’s clock.
ObsessOS does not necessarily need an autonomous AI continuously thinking in the background. It can capture reality continuously, while each new conversation turn gives ChatGPT an opportunity to service OVERWATCH before returning to the Obsession.
There should be only one reasoning intelligence: the ChatGPT Shawn is working with.
A second autonomous OVERWATCH agent would undermine the desired relationship. ObsessOS can store, queue, route, and execute software, but OVERWATCH judgment should come from the same ChatGPT working with Shawn.
One model context may be able to support two logical brains.
The BLACK/WHITE/GRAY model gives us a plausible way to separate OBSESSION cognition from OVERWATCH cognition even though ChatGPT cannot literally erase information it has seen: BLACK for the active Obsession, WHITE for OVERWATCH, and a very small GRAY kernel shared between them.
Shawn should not context-switch; ChatGPT should.
This may be the central bargain of OVERWATCH. During an Obsession, ChatGPT can temporarily switch into OVERWATCH, deal with outside reality, then re-anchor itself to the Obsession while Shawn remains cognitively inside one thing.
ObsessOS should function as the hard drive; ChatGPT should function as the working space.
Important project understanding should not remain dependent on ChatGPT conversation history. Durable, committed project context belongs in ObsessOS and should be selectively loaded when needed.
Closeout can serve as the commit boundary for project knowledge.
New understanding developed during an Obsession can remain uncommitted while the Obsession is active. Closeout then updates the project’s durable context, giving OVERWATCH a stable “last committed truth” rather than exposing it to half-formed thinking.
Project context is easier to understand as a folder of named context files.
Rather than one giant project summary or separate “capsules,” durable project knowledge can be organized into small, coherent, independently loadable context files.
Tools and External Resources serve fundamentally different purposes.
Tools such as Lovable are deliberately used by ChatGPT while doing an OBSESSION. External Resources such as Quo exist because outside reality can change independently of the active Obsession and therefore need to participate in OVERWATCH.
External reality needs somewhere durable to knock because ChatGPT cannot receive webhooks directly.
One essential role of the ObsessOS backend is therefore surprisingly simple: preserve the fact that something happened outside until ChatGPT gets another execution opportunity to notice and deal with it.
Results
OVERWATCH / OBSESSION Operating Model
Established the core model that ObsessOS is the operating system, with OVERWATCH maintaining broad awareness and OBSESSION protecting one narrow focus. ChatGPT is the primary interface and the only reasoning intelligence.
ChatGPT-Native ObsessOS Architecture
Defined the target interaction model: Shawn works primarily in ChatGPT while ObsessOS provides durable state, project memory, ceremony, event handling, and MCP control underneath it.
BLACK / WHITE / GRAY Context Model
Created the logical two-brain model for using one ChatGPT as both OBSESSION and OVERWATCH: BLACK for active Obsession context, WHITE for OVERWATCH context, and a minimal GRAY kernel for safe switching between them.
ObsessOS Project Memory Model
Defined ObsessOS as the durable project “hard drive,” with projects represented as folders of independently loadable context files. Active work remains uncommitted until Closeout, which serves as the commit point.
Foundation Brick Set
Locked the first five architectural bricks and substantially clarified the sixth and seventh around Tools, External Resources, and Events, while intentionally leaving those final pieces unresolved until the model is fully understood.
Open threads
- Finish defining the relationship between External Resources, Events, and the ObsessOS mailbox.
- Test whether BLACK / WHITE / GRAY context switching is strong enough to protect an active Obsession.
- Define the stable MCP contract between ChatGPT and ObsessOS.
- Define how ObsessOS-aware ChatGPT projects boot, discover state, and resume an active Obsession.
- Define how Closeout updates, supersedes, and preserves project context files.
- Decide what OVERWATCH should do when long periods pass without a ChatGPT turn.
- Define authentication and account ownership for project-specific External Resources such as Quo, Gmail, and Calendar.
- Prove that the existing Lovable/Supabase ObsessOS backend can support the required MCP architecture.