The best AI automation habits I have came from DevOps, not AI

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. The model is the part everybody talks about. It is almost never the part that breaks the process.

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 are 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.