Automate without breaking everything

Getting an automation to work is easy. Getting one that keeps working, and that tells you the day it slips, is a different craft. The gap does not show at the demo: both versions run, both look impressive. It shows three weeks later, when an unforeseen case goes through, nobody notices, and the error spreads in silence all the way to a customer. Automating without breaking things is not about automating less. It is about automating while keeping, at every step, a way to see what is happening and to take back control.

Why can an automation that works turn against you?

Because automating means, first of all, taking a human out of the loop. As long as the task was manual, someone saw the odd cases go by, flinched at a wrong amount, fixed it without even naming the fix. That safety net is what you remove on go-live day. Replace it with nothing, and the automation does not make errors disappear: it makes them travel faster, and unwitnessed. A wrong entry repeated three hundred times a day is not three hundred times worse than a manual slip, it is a different kind of problem, because no one sees it before it has been through the whole system.

What should you automate first?

A repetitive task, with clear rules, whose errors can be recovered: that is the safest place to start. I go for high volume and low risk, where the gain is immediate and an incident stays recoverable. A task that is still fuzzy, or whose error is irreversible, is not a starting point: you stabilize it first, you do not automate it to discover it in production. Four criteria act as my filter. If you want concrete candidates, I listed seven in the automations that pay for themselves fast.

• It comes up often: the time saved adds up quickly, and you get to watch the automation behave over many cases rather than three.
• Its rules are explicit: if you cannot describe the decision by hand, a machine will not make it any better than you.
• An error can be undone: you can cancel, correct, replay, without a customer or an account keeping a permanent trace of it.
• The worst case is bearable: before wiring anything up, I know what happens if it all goes wrong, and I can live with it.

How do you make a workflow failure visible?

By designing how it breaks before how it works. A workflow should shout when it fails, not carry on as if nothing happened. In practice that means three things in the very first version: an alert that reaches a human when a run fails, readable logs that say what happened and not just that something did, and a clear status per run to tell apart what succeeded, failed, or ran halfway. Without that, an automation breaks down in silence, and you find out in the worst place possible: from a customer reporting it in your stead.

The reflex holds for a script as much as for AI. The moment a model enters the loop, monitoring becomes continuous rather than one-off, because quality can degrade without a single line crashing: that is the whole point of measuring an agent in production.

How do you keep control of an automation?

With three guardrails I put in place systematically from day one, never after the first incident.

• Human validation on irreversible or sensitive actions: the automation prepares, a human confirms with one click. You do not ask for that sign-off everywhere, only where an error cannot be undone.
• A kill switch to stop everything dead, without having to unplug the rest or read the code under pressure. The day something goes sideways, no one has time to work out how to turn it off.
• Hard limits: a cap on calls, on spend, on volume processed, so a runaway loop does not drain a budget or flood an inbox overnight.

Do you need a human in the loop everywhere?

No, and trying to put one everywhere kills the gain. A human on every step is the manual process with extra steps: you pay the cost of automation without collecting the benefit. The right question is not where you can add a human, but where an error becomes irreversible. That is where, and only where, you ask for confirmation.

• Sending money, or triggering a payment.
• Deleting data, especially with no recycle bin to fall back on.
• Writing to a customer, or publishing something in their name.
• Any action you cannot undo with a single button.

When is an automation ready to run on its own?

When you have seen it fail, and the failure went well. You never switch everything over at once. A new automation first runs alongside the existing process, on a small volume, while you compare what it produces to what a human would have done. As long as the two diverge, it is not ready, and finding that out now rather than in production is good news. You then widen the volume in steps, never in one block, keeping a way back at every stage. That discipline, more than the technology, separates a prototype from a system you can lean on: it is the heart of going from POC to production, and a pillar of a system's reliability.

A good automation is judged not by how it runs on day one, but by how it stops on the day it breaks.

Automation is still one of the most profitable levers I know, provided you treat the guardrails as part of the work, not an option to bolt on later. Putting visibility, kill switches, and human validation in the right place costs almost nothing when you do it from the start, and a great deal when you do it after the first incident. If you have an automation in mind, or one already running that quietly worries you, a first conversation is often enough to see where the real risks are: let's talk.