Insight
My best AI automation habits came from DevOps, not AI.
The model is the part everybody talks about. It is almost never the part that breaks the process.
Open the diagram description
A diagram of one automated process, drawn left to right, showing that the failures gather around the model rather than at it. The heading reads: where it actually breaks. Not the model. Around it. Underneath, a smaller line reads: operational failures with a model somewhere inside them. Four panels sit in a row, joined by arrows pointing right. Panel one, labelled intake, is titled per-service triggers, and says: early mark-as-read, one credential can no longer stop everything. Panel two, labelled registry, asks: seen this already? It says: duplicate delivery is normal, checked before anything is written. Panel three, labelled model, is titled the model step and says: almost never the part that breaks the process. It is drawn exactly like its neighbours, with no extra emphasis, because the article argues it is the quiet part. Panel four, labelled pays or deletes, is titled uncertain cases and says: routed to a person, deliberately, not as a fallback. From the bottom of all four panels an arrow drops straight down, under a small label reading: on failure, any of them. The four arrows land on one wide band that runs the full width of the picture and is outlined in the bright accent colour to mark it as the load-bearing piece. That band is labelled: one shared failure path. It says: any workflow that fails routes into it. The team gets an alert with the context. Error handling written per workflow decays per workflow. Below the band sit two short panels. On the left, labelled handover: documentation, a walkthrough, accounts in the client’s name. On the right, drawn as an empty box with a broken dashed outline in a warm brown to show a signal that never arrived, labelled without the shared path: a step failed silently, nobody found out until Thursday. A faint dashed line connects the shared failure band down to that empty box. The background is near black with a very faint grid.
The habits that keep an AI automation alive in production are not AI habits. They are the same five or six things that keep any production system alive, and I learned them running infrastructure long before I was building workflows with a model in the middle.
Why would infrastructure work have anything to say about an AI workflow?
Because both of them fail in the same places, and neither of them fails where you expect. An AI workflow does not usually break because the model gave a strange answer. It breaks because the same message arrived twice, or a token expired at 2am, or a step failed silently and nobody found out until Thursday. Those are operational failures with a model somewhere inside them, and operations has been solving them for decades.
Habit one: assume the message arrives twice
Duplicate delivery is normal, not exceptional. Design for it before it happens rather than after, because the version of the system that has already processed something twice is much harder to reason about than the version that cannot. In practice that means a registry of what has already been seen, keyed on something stable, checked before anything is written.
Habit two: one shared failure path, not one per workflow
Instead of adding custom error handling to every workflow, there is one shared failure path. Any workflow that fails routes into it, and the team gets an alert with the context.
Error handling written per workflow decays per workflow. Centralised, it stays consistent, and it stays maintained, because there is one thing to maintain.
Habit three: a credential is a single point of process failure
One expired token took down document intake. The fix was not simply reconnecting it. The intake was rebuilt on per-service triggers with early mark-as-read, so a single credential failure could no longer stop everything.
Fixing the token is not fixing the design. If one credential can stop the whole process, the credential is not the problem. The topology is.
Habit four: the person is part of the design
Somebody stays in the loop for anything that pays, deletes, or touches a customer record. Not as a fallback for when the automation is not good enough, but as a designed step, with the uncertain cases routed to it deliberately.
A system that escalates the cases it is unsure about is more useful than one that is confident about all of them.
Habit five: hand it over
Documentation, a walkthrough, and accounts in the client’s name. A system nobody else can operate is a dependency, not an asset, and the day it becomes somebody else’s problem should not be the day anyone finds that out.
None of these five habits is about AI. That is the point. Adding a model to a process changes what the process can do; it does not change what makes a process survive. If the reliability work is not there, the model just makes the failures arrive faster.
Around the model
What is checking your AI step?
Tell me where a model is doing work that nothing verifies. I will tell you what I would put around it.
Send Dan a message on WhatsApp (opens in a new tab)or email dan@burdetsky.xyz