Agents are not hard because they are clever. They are hard because they run: on a schedule, on a named machine, under an approval somebody has to be able to read at three in the morning.

Six essays from inside a small fleet: two machines, one scheduler, a handful of named agents, and the rules that exist because something broke on a specific afternoon.

Manifesto

Every rule on this page is dated to an incident. None were written in advance. That is not a boast; it is the honest hit rate of designing loops from first principles.

Write the rule the day after it breaks.

This publication is kept by one operator running a small fleet: two machines, a scheduler, a handful of agents with names, and a set of rules that exist because something went wrong at a particular hour on a particular day.

Nothing here is speculative architecture. The claims are deliberately narrow: they describe what has held under a loop that actually runs, and they say so plainly when something has not been tested yet.

The tone is deliberate too. No hype, no roadmap, no inevitability. Operated intelligence is unglamorous maintenance work, and writing about it should read like the work.

01 Before the act

Propose, then approve

Nothing consequential is self-authorized. The proposal leaves the process, a person decides, and the decision is recorded next to the thing it answers.

02 After the act

Check the effect, not the report

Success-shaped output means the call returned. Read the effect back from where it landed, and check negatives twice, because a broken read looks exactly like nothing there.

03 At the end

A loop that stops reports it stopped

Failure is silent by default. Every run emits its own ending: the loop, the host, the reason, the local time. A missing stop record is treated as a crash.

Featured
Loop engineering

Name the Bus

A scheduled agent loop is infrastructure. Until it has a name, a home machine, and a stop that reports itself, it is a rumour with a cron entry. 14 Aug 2026 · 9 min Read the essay