Why most AI automation projects fail in month four

The demo always works. The failure shows up weeks later, when nobody is watching and the person who built it has moved on to the next thing.

By Aaron Stalberg · 20 September 2026

Nearly every automation I have seen built in the last two years worked on the day it was shown. That is not the hard part any more. The hard part starts about a month in, and it is almost never the model's fault.

I have built and maintained automation for my own products rather than for clients, which means I have been the person who has to live with it afterwards. That changes what you build. Here is where I have watched things break, in rough order of how often.

1. Nobody owns it

This is the big one, and it has nothing to do with technology. An automation gets built, it works, and then it belongs to nobody. There is no named person whose job it is to notice when it starts producing slightly wrong output. Everyone assumes someone else is watching.

The tell is what happens when it breaks. If the answer is "I don't know who set that up", you have found the reason it will fail.

2. Silent failure

Most automation fails quietly. The API returns something unexpected, the process writes a malformed row, and nothing raises an error because nothing was checking. You find out weeks later when the numbers look wrong, and by then you cannot tell which weeks were affected.

The fix is not sophisticated. Every automation needs somewhere to fail loudly, and needs someone notified once rather than a dashboard nobody opens. Alerting on every possible failure is the same as alerting on nothing.

3. Drift in the inputs

You build against the data you can see on the day. Six weeks later the inputs have changed: a form gained a field, a supplier renamed a product, a feed started sending dates in a different format, an upstream page was redesigned.

Language models make this worse rather than better in one specific way. A conventional script tends to throw an exception when the input shape changes. A model will often carry on happily and produce something plausible, which is far harder to detect. Confident wrong output is the expensive kind.

4. Nobody defined what good looks like

If you cannot state the acceptable error rate, you cannot tell whether the thing is working. "It looks about right" is not a specification, and it means the first time you discover a problem is when it has already been running for a month.

Spend the time up front writing down what a correct output looks like, and build something that checks a sample against it automatically. That single habit catches more problems than any amount of prompt-tuning.

5. It was built to be impressive

A lot of automation exists because the technology made it possible, not because anyone was drowning. The ones that last are unglamorous: moving data between two systems that do not talk to each other, producing a weekly report, reconciling a spreadsheet that someone was doing by hand every Monday.

If nobody was doing the task manually before, be suspicious of automating it. You may be automating a process that only exists because the tool now exists.

6. The exception path was never built

The happy path is easy. What happens when the record is missing, the email has two recipients, the amount is negative, or the model returns something that is not valid?

In my experience the exception path is where most of the real work lives, and it is the part that gets skipped when a project is built to demonstrate rather than to operate. An automation that handles 95% of cases and dumps the rest in a queue a human checks daily is worth more than one that tries to handle everything and fails invisibly on the remainder.

What I would do differently, in order

1. Name the owner before you build it. If there isn't one, don't start.
2. Write down what correct looks like, including what you will do with the exceptions.
3. Make failure loud and rare. One notification that means something beats a dashboard nobody reads.
4. Check a sample automatically, every run, against the definition you wrote.
5. Build the boring thing first. The task someone was already doing by hand.