Human + AI: A Multi-Window Operating System
Not hunting for a smarter model — designing an organization that keeps ordinary AIs from drifting.
This website was made by one person, but it was not made alone. As I write this, three AI windows are open on my machine: a management window has just issued the task card for this very article, an execution window is writing code, and a third is standing by for acceptance review. I sit in the middle, carrying messages.
The trouble with a single window
Anyone who has worked with an AI over a long stretch has probably run into the same thing: the longer the conversation, the more it behaves like an exhausted colleague. Once the context fills up, earlier agreements quietly fall out of memory; it cheerfully announces “everything is done,” and when you check, the tests were never run. This is not a defect of any particular model — it is a structural problem of long conversations: memory is finite, and self-acceptance is inherently untrustworthy.
My answer was not to wait for a stronger model, but to change the organizational structure.
Managing AIs like a small team
These days I set up a fixed “workbench” for every project, with roughly these rules:
- The management window does exactly three things: writes architecture decisions, opens task cards, and runs acceptance. It never writes a line of product code.
- Execution windows work from task cards. A task card is a contract: goal, boundaries, and acceptance criteria listed item by item, ticked off item by item.
- I am the message bus. Windows never talk to each other directly; every instruction and every result passes through me. It looks inefficient, but it is the heart of the governance: every relay is one more chance for human review.
A few disciplines back this up. “Verified” must mean “command + output” — a bare “should be fine” does not count. The window that writes the code never accepts its own work: acceptance is run by a fresh-context window against a sealed exam whose questions the implementer never saw, precisely to prevent teaching-to-the-test. Windows can retire and be replaced at any time, with a fixed hand-off protocol; people come and go, the bench and the rules remain.
Where this habit comes from
One of its starting points was late June 2026, when I took apart my team’s flagship project. Following that codebase led me to open-source tools like superpowers — frameworks for “setting rules for the AI” — and I dissected them line by line, learning the architectural design thinking behind them. That process made one thing clear to me: an agent’s reliability does not come from the model itself; it comes from the structure of constraints around it. Once I put it to work, both the speed and the finished quality of my vibe coding visibly improved.
The longer I used it, though, the more I noticed that the thing actually giving me headaches sat outside its range. superpowers governs how one thing gets built correctly — brainstorm, spec, plan, test-driven work, closing review — at the scale of a single task on a single branch. What wore me down was how a long project avoids quietly drifting over months: context fills up, windows retire, architecture decisions get forgotten, and acceptance slowly turns into self-congratulation. That is a problem on a different axis; doing the first axis better does not solve it.
So I systematically distilled the tools and methods accumulated through my own vibe coding into murDrift — governance, research, continuity, cheat-proof acceptance, aimed squarely at drift across sessions, windows and months. It and superpowers are two orthogonal systems: usable together, and neither requires the other. The multi-window discipline in this article does not depend on any external framework to run.
| superpowers (obra · MIT) | murDrift | |
|---|---|---|
| Governs | how one thing gets built correctly | how a long project avoids drifting |
| Main chain | brainstorm → spec → plan → TDD → review → wrap-up | governance / research / continuity / cheat-proof acceptance |
| Time scale | one task, one branch | sessions, windows, months |
I carried that idea from “the runtime of a single agent” over to “the organization of many AI windows,” and ground out the process above through trial and error. The website you are reading went from empty repository to a live homepage in two days inside this very process — including this article: at this moment it is still a draft handed in by an execution window, and by the rules, it counts for nothing until I have revised it word by word.
If you, too, work with AI for the long haul, I have only one suggestion: don’t rush to find a smarter model. First, give your collaboration a constitution.