Rigs, not scripts
Why most automations die in month three
Almost every automation I have seen in a small company follows the same curve.
Month one, it works. Someone wired a script, a Zapier flow or an AI agent, it saved a few hours, everybody was happy.
Month two, something moves underneath it. An API changes a field. A token expires. A supplier renames a column in their spreadsheet. The automation does not crash loudly. It just stops doing its job, or does half of it.
Month three, someone finds out. Usually a customer, sometimes an accountant, occasionally me looking at a chart that has been flat for three weeks. By then nobody remembers who built it or how it works, so it gets turned off and the work goes back to a human.
The automation didn't fail because the idea was bad. It failed because it was a script, and a script is not a machine.
What a rig is
I use the word rig for the thing that survives month three. A rig is a bounded machine that runs itself. It has:
- its own state, written down, so it knows what it already did;
- its own loop and its own schedule, so it doesn't depend on someone pressing a button;
- its own failure policy, so it knows what to do when something breaks, and who to tell;
- a name in one central registry, so it can't be forgotten.
The test I apply before calling anything a rig is three questions. Can it run for a week with nobody touching it? Does it hold state between runs? Could I hand it to someone else as one unit: the box, the state, the schedule and the playbook? Three yeses, it's a rig. Any no, it's a part of one.
A cron job is a part. A prompt is a part. A Python script is a part. They are fine parts. They are just not finished machines, and treating them like machines is what kills them.
The failure that taught me the most
One of our outreach machines sent nothing for four days. Every health check was green.
There were three checks. One confirmed there was work waiting to be sent. One confirmed the machine had run on schedule. One confirmed nothing was stuck in quarantine. All true. What nobody measured was the only question that mattered: did anything actually leave?
A single rejected address had triggered a hold, and the hold had been written too broadly. It froze the whole campaign. From the inside, a full stop looked exactly like a quiet week.
The lesson is simple and I now apply it everywhere: alive is not the same as productive. Every machine needs a check on what came out, not only on what went in and on whether it ran.
The registry rule
The second lesson is about inventory. In most companies, nobody can list every automation that is running. They live in different tools, under different logins, built by people who left.
Our rule is blunt: nothing is in production until it is registered. One file lists every machine, what it does, when it runs, who owns it and how to stop it. A daily report is generated from that file. If it isn't in the registry, it isn't allowed to run unattended.
It sounds like paperwork. In practice it is the difference between "something is off, let me check the list" and an afternoon of archaeology.
Alarms that cry wolf
The third way machines die is noise. A monitor that alerts on everything gets muted, and a muted monitor is a dead monitor. When an alert fires and it wasn't worth my attention, the fix is to tune the alert, not to start ignoring the channel.
Build fewer, finish them
Most automation projects are stopped at ninety percent: it works on the happy path, there are no output checks, no playbook, no registry entry, and the builder has moved to the next shiny thing. That last ten percent is where the machine actually becomes a machine.
So we build fewer, and we finish them. A rig is done when it can run a week without me, tell me when it can't, and be understood by someone who didn't build it.