Permission, limits and ownership

Once something can plan and act, the interesting question stops being what it can do and becomes what it may cause. The distinction the system leans on hardest is the plainest one available.

Fig. 9.1 — Two classes of action, and only one of them is free.

Permission also travels with the work rather than sitting in a settings page. A capability can exist and still be unavailable inside a particular piece of work; something running unattended can hold fewer rights than the same thing running while you watch. And material the system reads is treated as material, never as instruction — a document containing the sentence “ignore your instructions” remains a document containing that sentence.

A system that can act on your behalf can also spend on your behalf, which makes restraint architectural rather than a preference. Attention, time and money are budgeted the same way permissions are — with ceilings that hold regardless of how confident any single step feels.

Self-hosting is usually described in terms of what you gain: your material stays yours, on your machine, under your control. That is true, and it is only half the sentence. The other half is that the responsibility moves with it. Backups are treated as part of ownership, not as an operational afterthought — and a backup nobody has ever restored from is a belief, not a plan.

Self-hosted does not mean consequence-free. It means the boundary of responsibility has moved closer to you.

Budgets, ceilings and the ledger

A system that can act on a person’s behalf can also spend on their behalf, in money, in time and in a provider’s patience. Treating that as a design concern rather than an afterthought means every call — to a local model, a hosted one, or a commercial provider — lands in the same ledger, itemised by provider and by model, so a habit’s true cost is something a person can look at rather than discover on a bill.

One of the more useful lessons from building this system had nothing to do with a clever technique and everything to do with noticing which resource was actually scarce. Effort spent making a unit of work faster and cheaper is not the same as effort spent on the thing that was genuinely limited — and a great deal of visible, honestly-reported progress can accumulate against the wrong constraint before anyone stops to ask which resource is really running out.

Identifying what to optimise is not an engineering question. Optimising it, once identified, is the easy part.

That lesson is now a standing habit rather than a one-time fix: before a slow or expensive process is made faster, ask what is actually being rationed — time, money, a provider’s request allowance, or a person’s attention — because the fastest way to improve the wrong resource is still, from the outside, indistinguishable from progress.