The case against the autopilot toggle

Read literally, a toggle asks: do you want the software to act without you, on anything, until you come back and turn it off.

Nobody wants that, which is why the switch is usually off. What people want is much more specific and much less binary. They want the thing that pulls a budget back when something is obviously wrong to happen at three in the morning without anybody being woken. They want the thing that doubles a budget to involve them. They want a run of small changes that adds up to a large one to be treated as a large one. They want to be able to say what happened afterwards.

None of that is a position on a switch. Each of them is a statement about a particular kind of change, and the toggle has no vocabulary for any of it.

The toggle assumes autonomy is a level — a single dial from cautious to bold that can be set once and applies to everything.

It is not a level. It is a property of each change, and the relevant properties are ordinary and specific. Which operation is it. Which way is the number moving. How far from where it is now. In what currency. Against what previous value, and is there one.

Answer those and you can describe the grant in a sentence somebody would sign. Leave them unanswered and the grant is "do things", which is why the switch is off in most accounts that have one.

The three-level slider is the common improvement and it is still wrong, because conservative and aggressive are adjectives about temperament rather than statements about what may happen. A person moving that slider has been asked to characterise the software's personality, not to decide what it may do.

A rule, written by you, that names which connection it covers, which operations it may clear, which direction a number may move, the largest amount it may clear in a stated currency, and how far the number may move from where it is now as a percentage of its current value.

Five fields, four of them doing real work, and the whole thing reads as a sentence. Clear pauses and budget decreases on this connection, up to this amount, no more than this far in one step.

The last field is the one that gets forgotten and it is the one that separates a rule from a hope. A grant with a ceiling and no distance will happily take a budget to almost nothing, because almost nothing is comfortably under any ceiling you would have written. The distance is the field that notices the size of the step rather than the size of the destination.

And some things should not be grantable at all. Creating something has no previous value and therefore no direction and no distance to bound, so there is nothing for a rule to hold. A removal on some platforms is terminal. A change whose direction cannot be read — no previous value, or a budget that switched between daily and lifetime, which are different money — cannot be judged, and at a gate that spends money, cannot-tell has to be a refusal.

The toggle's deepest problem is not that it grants too much. It is that it grants without recording what it granted.

The alternative requires every applied change to carry the authority that cleared it: you, a credential you minted, or a rule you wrote, named on the row. And it requires the change to carry the state it would change from, so that the inverse is always available as an ordinary draft rather than a privileged rollback path.

That combination is what lets somebody grant automation without anxiety. Not because nothing can go wrong, but because when something does, the questions have answers: what changed, from what, who or what cleared it, and what would put it back.

None of which works without the substrate underneath it. Connections read. A change is a record before it is an effect, carrying what it would replace and what it survived. Clearing it is an act with an author — you, or a rule you wrote — and the author is on the row. And the last step is gated by somebody other than us: no platform write reaches a customer account until that platform has granted write access, which is why applying a cleared change is in private beta.

None of this is an argument against autopilot as a destination. Software that does more of the work is the point, and pretending otherwise would be a strange position for anybody building it.

The argument is against the word as a promise on its own. Autopilot within limits you wrote, on a record you can read, with an inverse available, is a description of something. Autopilot as a switch is a description of nothing, and the reason it keeps appearing is that it is much easier to build than the thing it gestures at.

The tell is what happens after somebody turns it on. If the answer is that they watch it nervously for a week and then stop looking, the product has transferred anxiety rather than work.

When you are evaluating something that offers to act on your accounts, ask what the narrowest thing you can grant is. If the answer is a switch, the product has one setting and a marketing department. If the answer is a sentence with a direction and a distance in it, somebody has thought about the incident before the demo.

Then ask what the record says afterwards, and specifically whether it distinguishes a change you approved from one an automation cleared. A system that flattens those two is one that cannot tell you what it did on your behalf.

Why every change is a draft is the unit that makes the alternative possible, and What an approval policy should say is how to write the sentence.