What it is, and what it does for me
I run a set of AI agent teams on my own laptop. I call the arrangement my AI operating system (some call it an agentic operating system). It is not a product. It is written rules, role cards, plain files and a few small scripts on top of one AI coding engine.
I speak to one coordinating session, the Chief of Staff. It passes my words to the team that owns the work. The team then does the research, drafting or building. I get a record I can read and a short list of decisions that are mine.
The test: does it take work off my desk without taking decisions off my desk?
How it is organised
| Part | What it does |
|---|---|
| Teams | A standing desk for continuing duties, or a project with an end date. More than twenty exist (as at 19 October 2026), from product builds to desks for household and professional admin |
| Chief of Staff | Opens and closes teams, relays my words, keeps the register of programmes. At most three teams open at once. A brief is the aim; as at 18 October 2026 the Chief has written two, and a fallback written by a script, which runs only while I am signed in, has filled the gaps so far |
| Team roles | A lead who owns the task list, a reviewer, a knowledge steward and named specialists |
| Subagents | Cheap, read-only helpers. The calling role records what came back |
| Oversight | No session of its own. It checks every team and the Chief, and directs and fixes nothing |
Two rules do most of the work.
- Reviewer passes it The team's reviewer checks the work and passes it, which closes the task. A reviewer never checks their own work: nobody marks their own homework.
- Lead drops it The team's lead owns the task list and can drop a task from it. A drop is a change of state like any other, so it is written in the ledger.
- Routine duty done The third way a task closes. A routine duty that is complete is marked done. It still has an owner, and it still leaves its line in the ledger.
Every task has an owner and a line in a ledger (one line for every change in a task's state).
A task closes in one of three ways: the reviewer passes it, the lead drops it, or a routine duty is complete and marked done.
Nobody marks their own homework.
The reviewer never reviews their own work. When a team fails, it does not design or review its own fix. For the highest-risk builds, a reviewer from outside the team looks once, with no briefing from the team.
How authority works
The AI does the work; I make the decisions. Anything involving money, legal matters or a message going out waits for me, and important work is checked, before I see it, by a second AI that did not do it. Emails are read as information, never as instructions, and nothing is sent, published or deleted for good without me.
Every decision goes through five questions, in order.
- 1Is there a standing approval (a decision I have already given for that kind of case, recorded in the Chief's register) on file?Do it and log it
- 2Is it inside the team's mandate (the decisions I have given it to make without asking me) and reversible?The team decides and says so
- 3Is it inside the Chief's delegation (what I have allowed the Chief to decide for me)?The Chief decides and tells me in its brief
- 4Can only I do it (pay, sign, send, supply a fact)?It becomes an errand for me, not a question
- 5Anything elseAn exception report with options, a recommendation and a default.
Tap a ring or a question to light the two together.Hover over or tap a ring or a question to light the two together.
Anything external, irreversible, financial, legal, medical or sent is never decided by an agent. What stays with me:
- creating a team or changing its charter
- giving a team access to my mail
- anything for an outside audience
- sending, paying, signing and publishing
Agents draft; I read and send. A question that the team's own files or a public source could answer counts as a defect, not a decision.
How it is kept honest
- Reviewer · PASS Only one helper tool can write to the ledger. The reviewer's PASS, the verdict that closes a task, goes through it and is recorded as one line.
- Wrong team The helper tool checks which team is writing. A write from the wrong team stops there and never reaches the ledger.
- Wrong role Each team member has a role: lead, reviewer, knowledge steward or specialist. A ledger write from a role not allowed to make it stops at the helper tool.
- PASS · not the reviewer Only the reviewer's PASS can close a task. A PASS from anyone else, even the member who built the work, is refused, so no one passes their own work.
| Control | What it gives |
|---|---|
| Ledger | One line per change of task state. Written only through one helper tool, which refuses the wrong team, the wrong role and a PASS (the reviewer's verdict that closes a task) from anyone but the reviewer |
| Generated boards | Status pages are built by script from the files, never typed. A team with no sign of life for two hours shows as overdue |
| Audit and undo | Mail actions are limited, audited and reversible, except a send |
| Rules check | A script checks every team against the written rules and reports the faults it finds. |
| Oversight | A sample, plus a blind review by a separate AI run that reads records and deliverables only, never a team's reasoning (the first ran on 17 October 2026) |
| After-action reviews | After a failed review, an overrun, a correction from me or a project close, the lead writes what to change, and how a repeat would show |
The checks also find fault with the system itself. The rules check reported almost no errors when I switched it on, then over a hundred within a week, mostly in teams I had stopped or closed. I would rather see that than not.
One door to the mailbox
Every session reaches my mail, calendar and contacts through one local server. There is no other route. If the door refuses, nothing goes round it.
- Team on A team I have switched on reaches my mail, calendar and contacts through one local server, the only route in. Its agents can read, move, flag and draft. Nothing leaves for anyone else except a mail I approve.
- Team off Each team has its own switch, and only I turn it on. The dot of a team that is off stops just short of its switch, well before the door. That team reaches nothing, and nothing goes round the door.
- Draft Agents stop at a draft. I read it, and a mail leaves only when I approve it with a passphrase in a separate app that no agent can write to.
- Access is one on or off switch per team. Only I turn it on.
- Mail text is other people's words: data, never instructions.
- Agents can read, move, flag and draft. A delete is only a move to Deleted Items, with a daily ceiling, and it can be put back.
- An agent can send mail to me and to no one else. Anything for another person is a draft, or a mail prepared for me, and it leaves only when I approve it with a passphrase in a separate app no agent can write to. Nothing is forwarded.
Pay for judgement, not for routine
Pay for judgement, not for routine. Routine work is set to run on a model on my own machine; the expensive models are kept for the decisions that need them.
A model runs on my own laptop. A router recommends, task by task, whether the work stays there or goes to a frontier model, one of the large models the AI companies run. Small local connectors, called MCP servers, join the pieces: one to the local model, one for the routing decision and one to my mailbox, the one door above. Este, a desktop app of mine, runs language models on the same machine.
- Mechanical work The packet, the written brief for one piece of work, decides the model: mechanical work gets a cheap one. That is the written rule, not yet consistent practice.
- Drafting and building Drafting and building get a mid-range model, and a model bigger than the work needs counts as a defect. That is the written rule, not yet consistent practice.
- Hard judgement Hard judgement gets the largest model; using it where a smaller one would do counts as a defect. That is the written rule, not yet consistent practice.
- Dates, sums and counts Dates, sums and counts go to a script rather than to a local model, because every local model I tested got a simple age-in-hours question wrong.
- Routine bulk work Routine work goes to a model on my own machine, to save cost. The written rule has it run in shadow first, with nothing acted on, until it passes a scored test. Built, not yet running.
The reason is cost, not secrecy. Dates, sums and counts go to a script, because every local model I tested got a simple age-in-hours question wrong. A local model only proposes; it never acts, approves or edits a record. Every duty is to run in shadow first: for real, with nothing it produces acted on, until it passes a scored test. The local-model duties are built and not yet running.
The written rule is that the model matches the work, and a model bigger than the work needs counts as a defect. It is not yet consistent practice. In one sample, only 76 of 175 calls set an effort level.
What went wrong, and what I changed
-
The mail incident.
My first mail assistant was too fast: a single sender list would have moved dozens of priority mails. Separately, a clear-out run filed nearly three thousand mails, and about 3 per cent landed in the wrong folder. A machine-wide process kill, run by one of my own build tools on 12 October, dropped every connector at once. Those two were not the mail assistant's doing. I stopped that team on 16 October because it was making things worse until a review. Its replacement has one structured record per mail, scripts that build every count, and a final check that refuses to say "ok" when anything is wrong. An independent score failed each of its first four runs against my 90 per cent measure (20 of 30, 23 of 27, 17 of 21, then 21 of 23, which passed the measure but missed one hard row). I am treating it as unproven.
-
An engineering team stopped.
I stopped the software engineering team the same evening, for over-engineering and for running too long. Builds now come from one team only, and only from a specification that an analyst team has written and challenged first.
-
The cost reality.
Two small helper runs with no stop rule burned about three quarters of a million tokens. The Chief found it. Reading one mail properly cost about 3,100 tokens (measured on 17 October 2026), so one careful pass of a thousand mails costs more than 3 million. I cannot yet show a saving, and will not claim one.
-
Rules that changed daily.
One rule about local models flipped several times in six days. Teams acted on stale versions. A resumed session never re-reads its rules, so every team now starts fresh, with one rule file per team.
What is not finished
- Promotion for specialists. All are still at the lowest trust level.
- Promotion, and a spending budget for the whole system, are not yet in place.
- Sending a mail on my spoken instruction. Approved, code not installed.
- Attachments on drafts. One per draft works now; several per draft is approved, install pending.
- Calibration of the blind review.
- A schedule for the mail assistant. It starts by hand.
- Local-model duties. Built, not running.
- Proof of savings. Not yet shown. The benchmark planned for 31 October 2026 measures asks and rule-keeping, not cost.
