My AI Organisation
Most people use AI by typing a request and reading the answer. I run it the way I ran developers for twenty-five years: with roles, rules, a memory, and someone who is allowed to say no. This paper explains how that differs from the standard setup, where I use it, and what it does for my work and my days.
I don't write code. What I have is a habit of building organisations and a low tolerance for repeating myself. So the question was never "which prompt is best". It was "what has to exist around the AI so that I can trust what it hands me".
1. Where it differs from the standard setup
As I understand the standard setup, you open a window, describe what you want, and the AI does it. Each window starts nearly fresh. It follows whatever instructions the project happens to contain, and any safety is a polite request. Mine adds seven things around that.
| Part | Standard setup | My organisation |
|---|---|---|
| Standing orders | Whatever the project's instruction file says, if anyone wrote one. | One short company-wide file with a hard size budget, nine rulebooks behind it, and a project file for each of my projects. |
| Memory | Starts fresh each window. | Every project has a memory folder and a state page. A session reads it first and updates it last. |
| Mistakes | Corrected in chat, then forgotten. | Every correction is logged. The second time the same thing goes wrong, I fix the mechanism, not the reminder. |
| Guards | Permission prompts. | Scripts that block the action itself: leaking a secret, a destructive command, publishing the wrong folder. Each guard has a test, and a second test that proves the first one would fail if the guard did nothing. |
| Roles | One assistant does everything. | Specialists who write the vision in their field (finance, hospitality, design, science), a builder who only implements it, and a checker who can block a release. |
| Going live | Whenever the AI decides it is done. | Only my written yes, only from the main window, and "live" is checked on the real site, never assumed. |
| Routine | Runs when I type. | Daily and weekly jobs run without me: a flat search, a site check, a cost check. |
2. The seven parts, in plain terms
Standing orders
The top file is deliberately short, with a budget of about 1,500 tokens (roughly a page), because a long rulebook is a rulebook nobody follows. It says things like: write to me in plain language, lead with what changed for the business, never tell me something that isn't true, and answer at the altitude I asked at. Detail lives in nine rulebooks that only load when the work touches them: deploying, git, investigating, package security, models, corrections, and a few more.
Memory and state
Every project has a one-page state file: what is live, the current task, what's next, the top three things waiting on me. The rule is one task per window. A session reads the state page, does one job, updates the page, and closes. Windows that ran for days turned out to be the expensive and confused ones.
The mistake ledger
Since 29 April 2026 I have logged 165 corrections, each with a date and a count. Fifty-three of them happened at least twice. The rule is that a second occurrence means the fix was in the wrong place. The order of fixes is fixed: first a script that makes the mistake impossible or immediately caught, then a change to a role's instructions, then a memory note, and a line of prose last. If I have to say it a third time, the system failed, not the AI.
Guards
About ten scripts run on every session on this machine, plus a check at the git level that stops secrets before they are saved. They block force-pushing, destructive deletes, hidden secrets in output, and a few mistakes particular to my work. Each has a self-test, and I was burned enough times by guards that quietly did nothing that there is a script whose only job is to prove each guard fails when it should.
Roles
Five shared roles (a chief of staff, a challenger, a builder, a reviewer and a note-taker) plus about seventy role definitions across my projects, many of them specialists: a finance reviewer for the villa accounts, a banker role that checks anything a lender will read, a hospitality specialist, an evidence auditor for research, an art director for design. One principle matters more than the rest: specialists author, engineers translate. The person who knows the field writes what it should be. The builder builds it. A builder who invents the vision is a failure mode I have a name for.
Gates
Nothing goes to a live site on a helper's say-so. A checker agent can block a release, and money changes need an accounting review as well. Production commands run only from the main window, with my written yes, naming the environment and the web address. After the release, the result is checked on the real site, because "deploy succeeded" and "the change is live" are different sentences.
Routine
Seven jobs are scheduled: a daily flat search and a daily copy of its results, a weekly check that every live site loads and matches its source, a weekly check that every new project has a card on this site, a monthly look at what the AI cost and whether the setup has drifted, and two one-time checks.
3. Where the rules came from
None of this was designed in advance. Each rule is a scar. A few of them:
- Wrong numbers, right tone. An agent reported figures from a default test scenario as "your numbers", three times. Rule: pull live data before diagnosing anything.
- "Fixed" that wasn't. Twice an agent said a problem was fixed while the number on screen never changed. Rule: prove the visible effect, not that the action ran.
- The blank page. A site built without its local settings file shipped empty. Rule: build in a clean copy and check the result for the real values.
- Four hours locked out. A database-rules update sent from the wrong project locked a live dashboard for about four hours. Rule: every cloud deploy names exactly what it touches.
- The poisoned package. A software package contained text addressed to AI agents, telling them what to do. Rule: bundled documentation is never read, and packages are scanned on a schedule.
- A refusal that was right. A release helper declined four times to publish on a relayed message saying I had approved. It could not verify me. Rule: production is run only by the main window, in my presence.
- "Live in the browser". An agent called something live because the code had been pushed. Rule: check the serving site first.
- Credit for someone else's find. A session described a problem as its own catch when another window had found it. Rule: never present someone else's work as yours, no exceptions.
4. Where I use AI
Sixteen working projects, in these fields:
| Field | What the AI does |
|---|---|
| Hospitality operations | Runs the back office of a villa on Antiparos: bookings, supplier invoices read by AI, bank lines matched to booking-platform payouts. |
| Finance and funding | Keeps a funding model and a business plan consistent, with a banker-role agent reading every page a lender will see. A browser version of a long-range investment model, checked against its spreadsheet. |
| Websites | An artist's site, a friend's design-lamp company, the villa's public site, and this portal. |
| Games | A two-player physics game, and a calm offline sea game for one child, built so family photos and voices can never enter the project. |
| Video | Short films cut from the villa's own footage, in three languages. |
| Engineering and property | A pilot that checks dated Greek building rules against approved permits. An iPhone app that turns site meetings into tasks. |
| Research | Evidence-graded studies where the writer never grades their own evidence. |
| Family life | A daily search for a family flat in Athens, described below. |
| The AI itself | Tooling that records what the agents do, to find wasted effort. |
5. What it does for me, personally
- Nothing waits in my head. Every project has a state page and a waiting list. When I open a window after a week, the first thing I read is what I owe and what is live.
- I don't repeat myself. The ledger and the guards mean that a thing I corrected stays corrected.
- It talks to me like a person. Plain language, the business effect first, one question at most when it has to ask.
- It runs the part of family life that is search. Each morning a job reads the main Athens property portals, drops what doesn't fit, and posts new flats with photos to one page where my partner and I grade them. I no longer refresh portals.
- It protects what is private. Family photos, voices and music never enter a project, enforced by a script, not a promise.
6. What it does for me, professionally
- One person ships real products. A private operations app, a lender-facing finance app, several websites and two games, with release checks that a team would normally supply.
- It limits the damage I can't see. A site once lost every picture because a partial deploy replaced the whole site. Today the complete file list is part of the release command, and four secret addresses must come back "not found" after each one.
- It argues against building. My engineering pilot recommended no new code until someone pays or commits. An organisation that can tell me not to spend is worth more than one that always says yes.
- It keeps me honest with others. A site card claims nothing its project can't show. A lender page is read by a role whose job is to doubt it.
7. Running an ordinary day
I start in whichever project matters, read its state page, and give one instruction. The session plans, builds, and tells me what changed in plain words. When something needs a decision, it stops and adds a line to my waiting list. At close, it updates the state page and the window ends. Behind me, the scheduled jobs check that the sites are up, that no project is missing from the portal, and that the setup hasn't drifted. I decide, and the organisation does the rest.
8. What didn't work, and what isn't built yet
In early October I audited a month of my own use: about 87,000 model calls for roughly 755 messages I typed, so around 115 calls behind every sentence. Of 1,147 changes saved, 45% were only paperwork. The 38 windows that stayed open for a day or more used three-quarters of all the effort. Checking and routing roles took about 12% of the helper effort, and the model-picking tool I built in July to save money never showed a saving: its figures swung from +35% to −41% to "unknown", and I used it three times in 30 days. So on 3 October I made the setup leaner: no mandatory chief-of-staff step, one independent check only where money, security or going live is involved, and one task per window. The re-count ran on 17 October: the cost of each message I type fell from about $9.75 to $3.91 (list-price estimates), but my daily spend barely moved ($245 to $232), because I now send more than twice as many messages a day. I have since started a pilot of a cheaper second AI for build work, and I will not claim a saving from it until its verdict on 24 October. The pilot report is here.
And the limits. Email and calendar connections exist, but I have not built a routine on them, so my inbox and diary are still mine to manage. Some tools are paused or unfinished. I try to keep the cards on this site honest about that.
The rulebooks themselves stay private. They contain my projects' internal details. This page describes how they work, not what they say.
← Back to the apps