Raian Pollock

The method

How I decide what to automate, what runs on its own, and what a person must still approve. Written down, with the numbers that made each rule.

All work

Running a company on AI agents (small programs that each do one job on a schedule) is an operating question before it's a tools question. Which work moves first? How far does each piece get trusted, and what is left behind when the person who built it is gone? My last company ran this way for real, and every rule here was paid for by something that went wrong in production. The receipt is on each one.

Where to start: sort the work before touching any tool

The exercise takes one team and one month of timesheets. Mark every hour that produced the same document out of the same handful of inputs, month after month. That pile is the work an agent can carry. The hours spent on judgment, relationships and exceptions stay human. They get more room.

In a software company the biggest pile usually sits in the seams between functions. The same fact about a customer gets re-typed from the sales notes into the delivery plan, then into the invoice, then into the support thread. Every re-typing is unpaid work and a fresh chance to get it wrong. So the first thing worth building is usually boring: one place where a fact gets collected once, and every report reuses it.

cost of making it safe → value released → START HERE reporting & dashboards standing health checks research & enrichment drafting messages, behind approval internal admin & filing moving money promises to customers a person, always runs first runs behind a gate cost of making it safe → value released → START HERE reporting & dashboards standing health checks research & enrichment drafting messages, behind approval internal admin & filing moving money promises to customers a person, always runs first runs behind a gate
Where the early work goes. The dashed circles never run alone, whatever the value.

Reporting goes first because it's the piece that tells you whether everything else works. At my last company the standing checks it produced found 750 named problems in 100 days. The lag between something breaking and someone knowing dropped from "when a customer writes in" to minutes.

Three classes of action, and a line that never moves

Before an agent touches anything real, every action it could take gets classified. There are three classes, and the boundary between the second and the third carries the whole safety model.

Advises reads, watches, reports. No side effects, so it runs freely. Prepares for approval does the work up to the moment of action. A person releases it. the approval line Acts within rules pre-agreed actions inside written limits. Logged, reversible, checked. Advises reads, watches, reports. No side effects, so it runs freely. Prepares for approval does the work up to the moment of action. A person releases it. the approval line Acts within rules pre-agreed actions inside written limits. Logged, reversible, checked.
Every action an agent can take belongs to one class. Each one below the line carries four written answers before it is allowed to exist: who owns it, what proves it ran, how it fails, and how it gets undone.

Two numbers show where the line actually sat at my last company. Of the 32 written procedures the company ran on, 21 named something that needed my yes before it was allowed to happen. And 30 of the 56 agents used no AI model at all: their work was rules-shaped, so it ran as plain software. The model only appears where judgment or language is genuinely needed, because plain software is cheaper and easier to trust.

The line moves in one direction only. A new action starts above it and earns its way down after enough clean approvals in a row. It never starts below. My own spending rule exists because four cost estimates in a row once missed by three times. Since then, any sizeable job states its expected cost and gets a recorded approval before the tools will run it.

The working rules

Each one was written after a specific failure or a specific save, and the receipt is on the card.

  • Research the world before you design

    Nothing non-trivial gets planned from a blank page. Ten minutes first on how the best teams already solved this class of problem.

    Nine searches change nothing. The tenth saves a month, and there is no way to know in advance which one it will be.

  • Every system says how you would know it broke

    A plan states, on the same line as the feature, what breaks loudly when it fails and which check proves it ran today.

    Written after a monitor died behind a certificate error and stayed dead for seven days while its dashboard looked fine.

  • The report is not the work

    A "done" report gets checked against the thing itself: read the change, open the result the way a user would.

    A confident survey of what had shipped made four claims; three were spot-checked, and all three held. The fourth, the one skipped, sat on 865 lines nobody had read.

  • Turn the lesson into a gate

    A lesson worth keeping is moved out of prose and into a mechanism: a check that sits in the path of the action, so nobody has to remember it.

    My sending tools stop a batch when bounces cross 3%. Each gate costs an afternoon. The lesson it encodes usually cost a week.

  • Try to kill your own favorite explanation

    Any question that decides direction starts with three explanations that can't all be true, plus a written note of what finding would kill each one.

    Four research agents once agreed with the framing they were given, with sources, which proved nothing. The method comes from CIA analytic tradecraft.