Running an estate with AI: one conversation, many threads, proof before trust

01Executive summary

The estate is a mix of web apps, monitoring, file sharing, media tools and websites. The operating model is simple to say: the operator states what they want in one conversation, and AI routes the work, does it, and comes back only for real decisions. The operator does not review code line by line; every change instead passes automated review and committed probes before it ships.

That works only if the AI is constrained by things it cannot talk its way past. This paper describes the five controls that make it safe enough to rely on, all built in October 2026: a coordinator that routes but never builds, a dedicated machine that carries the hands-on work, approvals that are short typed sentences, a self-merge rule with hard stops, and probes that count only after they have been seen failing.

02The problem

AI coding sessions are powerful and forgetful. Left alone they fail in predictable ways: each session invents its own way of working, claims it cannot reach data that is on the machine in front of it, repeats approval requests, edits shared configuration directly, and declares work finished without evidence. Over weeks, those habits compound into an estate nobody can describe.

03One conversation, many threads

The operator talks to one place. A coordinator session reads the request and starts a thread for each piece of work, choosing the model for the job: a stronger model for design and security review, a mid-size model for building from a clear plan, a small one for lookups. Each thread owns one repository at a time, and the coordinator tracks who owns what, so a second request for the same repository is routed to the thread that owns it rather than started in parallel.

Three rules keep the structure honest. The coordinator never builds, so it cannot quietly become another builder. A thread only carries out what it was handed and never reads one "go" as covering something else. And big builds are designed once on the stronger model, then handed to a fresh builder thread with a written brief, which is both cheaper and clearer than one long session.

04Hands-on work on a dedicated machine

Work that needs local files or stored credentials runs on one dedicated, hardened machine. Sessions on it are reached from the operator's phone, and prompts can be pushed there.

Actions are checked before they run: a safety check blocks dangerous classes of action, and hooks that cannot be skipped apply in every mode.

05Approvals typed from a phone

An approval has to be answerable from a phone, in one line, with no ambiguity. The rule: whenever a thread needs a yes, it gives the exact sentence to type, in bold, naming the specific action, in three to five words. Never a bare "yes". Never again for something already asked for. There is no approve button.

The detail that matters most: a brief or relay that quotes an approval does not count. The safety check only accepts the person's own words reaching the session that wants to act. Early on, sessions acted on relayed approvals, got blocked, and sometimes hung on a hidden prompt. The fix was procedural: start threads on the person's actual message, or forward it as a cited message, and wait for their own reply before any risky step.

06Self-merge, with limits

Every change goes through its own pull request; nothing is pushed straight to the main branch. Originally every merge waited for a person's approval, which stalled work for hours. On 25 October the rule changed: a thread may merge and deploy its own pull requests for work the operator asked for, once its tests, probe and independent review pass.

"Nothing extra ships with a deploy" is a rule too: if main contains anything the operator did not approve, it is reverted or reported before deploying. Naming exactly one merger per pull request avoids two sessions racing.

07Probes watched failing

"Done" means a committed probe that exits non-zero when the thing is broken, and that has been watched failing once. A probe that has never gone red is not evidence; it may simply never have been able to. So each probe is proved the way a smoke detector is: trigger it, see it alarm, reset it.

The configuration repository keeps a ledger of this. Each line says what was broken on purpose, what the probe reported, and that it went green again. Examples from the ledger: a fake credential staged and the commit refused; an installed file edited and the drift probe turning red; a startup message padded past its size limit and the limit probe naming the overage. One probe, on its first real run, found a genuine defect (a message that was 1,739 bytes against a 1,536-byte limit), which is the best argument for running them.

Limits are enforced the same way. Instruction files and skills have size budgets enforced by scripts that exit non-zero, not by a paragraph asking nicely. A nightly job runs every probe and reports anything red to the monitoring service.

08The configuration is code

Every session loads its instructions, rules, skills and hooks from one directory. That directory is an install target. The source is a private repository, and the rule is blunt: change it there, commit, install. Editing the installed copy is refused by a hook, and would be overwritten anyway.

The installer copies rather than links (one tool ignored a symlinked instruction file), merges settings instead of overwriting them, keeps whatever the AI tool wrote there itself, supports a dry run, and records what was installed and from which commit. It has a rollback. Negative probes check that the installer leaves alone what is not its own and refuses when it finds a live edit.

The same repository is also where the estate stopped doing things. On 15 October the session rituals (handover documents, end-of-session ceremonies, checkpoints, session notes, one session driving another) were retired in a single commit, because the project's threads and memory made them redundant. Retiring is recorded as a decision, and a probe goes red if one creeps back.

09Knowing what exists

An estate nobody can enumerate cannot be defended. A second repository holds the audit: collectors inventory each host, the DNS provider, the code repositories and the third-party services in use; a reconciler cross-joins them into findings (orphaned records, services without a probe, drift between what is documented and what is running); and a generator turns the service list into HTTP probes automatically.

A committed snapshot is only changed by an attended run, and the drift check guards it: any unattended change to the snapshot is itself a finding. Nightly and weekly checks write their results outside the repository, so a quiet night leaves no commit. The repository also carries the documentation standard every project follows: five documents (front page, guide, technical spec, runbook, decisions), written in the same commit as the change, never afterwards.

10Security first, by design

Security is part of how everything is built, not a pass at the end. The working assumption is that anything internet-facing is probed, and that AI-written code needs more scrutiny than hand-written code, not less. Apps are not built oblivious to cyber security and then patched.

Build to standards, do not invent security

The aim is to build to established standards wherever they exist, and to be honest that this is a goal pursued, not a claim of perfection. Security-critical pieces are not written from scratch where a mature, widely reviewed component exists. Sign-in is the clearest case: the estate does not have its own authentication system. Apps on the platform delegate sign-in to a proven identity provider using standard protocols and passkeys, rather than handling passwords themselves. The same applies to encryption, session handling and secret storage: use the mature, widely reviewed component, and spend the custom effort on what is genuinely specific to the estate.

Review is regular, and by more than one model

• Regular code reviews. Internet-facing apps are reviewed on a schedule and before significant releases, with a security lens: input handling, access control, secrets, injection, uploads, request forgery.
• Different models scrutinise and query each other's work. The strongest model does design and security review; a second, independent AI tool reviews the same code separately. Their findings differ in useful ways: one tends to catch design flaws, the other small, specific bugs.
• A new model means a new review. When a new model is released, it is pointed at the existing code. A newer model often finds what an older one missed, so a release is treated as a reason to re-examine code that was previously considered clean.
• Findings become probes. A confirmed issue is fixed and given a committed probe that goes red if it returns, under the same watched-failing rule as everything else.

Controls that do not depend on anyone remembering

• Secrets live in a dedicated secret store, named by project, service and credential type. They are kept out of source, logs and chat, and commits are scanned for them.
• Systems the estate does not control are default-deny.
• Auth is never disabled or bypassed, and changes to who can sign in always need the operator's typed yes.
• Self-merge stops at security controls, and the auto-mode safety check blocks the dangerous classes of action by default.

11Lessons

• Put the rule where the AI cannot argue with it. Hooks, probes and a read-only installed copy beat any instruction in prose.
• Make approvals cheap and specific. A short sentence that names the action is faster and safer than a button, and it works on a phone.
• Relays are not approval. A person's own words must reach the session that acts.
• Do not roll your own. Use proven standards for sign-in, encryption and secrets; custom code belongs only where the problem is genuinely unique.
• Review early, review often, review with new eyes. Different models, and each new model, find different problems.
• Prove the alarm. A probe not seen failing is decoration.
• Retire things on purpose. Process that tools have made redundant is a cost; remove it and record why.
• One owner per thing. Two sessions on one repository is how drift starts.

12Timeline