One Human + a Team of AIs: My Multi-Window Operating System
Not hunting for a smarter model — designing an organization that keeps ordinary AIs from drifting.
AI-translated draft — pending human review. Read the Chinese original →
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 hand-off 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. Later, I went a step further and systematically distilled the tools and methods accumulated through my own vibe coding into murDrift — an engineering discipline that keeps a long-running project from quietly drifting.
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.