Uptime thinking: running AI like it's a phone system
Phone systems taught me a standard: when it breaks, someone can't call 911. AI automation deserves the same discipline, and almost nobody builds it that way.
I have spent years running voice infrastructure, and voice ruins you for sloppy engineering. When a web page is slow, people wait. When a phone system breaks, a business goes silent, and somewhere behind that there is always one call that genuinely matters. You learn to think in failure modes, because failure is not hypothetical. It is Tuesday.
Most AI automation I see in the wild is built like a weekend demo: it works when it works, nobody knows when it silently stopped, and the person who built it is the only one who can tell. Here is what infrastructure discipline looks like applied to AI, from my own production stack.
Every job reports in
Around 50 scheduled jobs run my operation. Every single one goes through a wrapper that logs the run, the outcome, the cost, and the failure if there was one, into a telemetry database. When something breaks at 6 a.m., I know by 6:05, from the system, not from noticing three days later that the morning brief stopped arriving.
Quotas and cost routing
AI calls cost money, and cost failures are silent. Every job carries a priority tier and a model assignment: cheap models for mechanical work, expensive models only where judgment pays for itself. Expensive jobs pre-gather their data with plain scripts so the AI spends its tokens thinking, not fetching. Some runs skip the AI entirely when there is nothing to do. Boring? Extremely. That is the point.
Backups you have actually restored
Every database has one owner, lives in one known place, and gets swept into nightly encrypted off-site backups. Credentials are backed up separately, also encrypted, and one passphrase, held in a password manager, unlocks the recovery path. If my main machine dies tonight, the automation comes back. I know because the restore path is scripted and documented, not assumed.
Writes are gated, everywhere
The same rule I apply to email applies to infrastructure: AI reads freely, but changing a server, a phone route, or a client tenant requires explicit flags and per-action confirmation, and the riskiest operations stay manual. An AI that can read everything and change nothing is already transformative. An AI that can change things quietly is an incident report you have not written yet.
The bar
If you are putting AI into a business process, hold it to the phone-system bar: you should know it broke before the customer does, you should know what it costs per run, and you should be able to rebuild it from documentation. If a vendor cannot show you those three things, you are not buying automation. You are buying a demo with a monthly fee.
