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.
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 are you left holding if I disappear? 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.
The exercise I run in week one 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 I build is usually boring; one place where a fact gets collected once, and every report reuses it.
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.
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.
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.
These are the rules the practice runs on. Each one was written after a specific failure or a specific save, and the receipt is on the card.
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.
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.
A "done" report gets checked against the thing itself: read the change, open the result the way a user would.
A confident survey held up on 3 of 4 spot-checks. The fourth, the one skipped, sat on 865 lines nobody had read.
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.
Costs and results come from real runs, not from the plan. The plan is only the thing the measurement gets compared against.
A service planned at €30 to €90 per customer measured at about $10. A two-week audit found 91% of spend sitting on the most expensive models. Nobody had chosen that.
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.
The same discipline applies to my own work in your company. Nothing arrives all at once, and the first proof happens on one live piece of your work.
Map how the work actually moves and put baseline numbers on it. You keep the map and the sorted list whether or not we continue.
One workflow, end to end, with its checks and its approval line, running on real work. Small enough to switch off and real enough to judge.
Each new piece starts above the approval line and earns its way down. Your team keeps serving customers; nothing asks them to absorb a new system all at once.
Everything lands in your systems from day one. At the end you hold four things. A written statement of how the company decides. Procedures for the recurring work. Checks that sit in the path of the action. And the record of every correction, so no instruction is ever given twice.
The audit is where it starts, and it's priced as a fixed piece of work.