Why AI-built automations break, and how to make them last

A few days ago I spoke with a business owner whose automations kept breaking. They worked fine whenever he tested them on the scenarios he was used to. Then real work started flowing through, and they began failing in ways nobody could have predicted when the workflow was first designed.

That conversation felt like a small epiphany, because I hear something similar in a lot of my conversations lately. As AI tools get more capable, more founders are building their own automations, and I think that is a genuinely good thing. What is easy to miss at first is that a system which runs well on a few examples, and on the scenario you had in mind, is only the starting point. A well-architected system also knows what to do with the cases nobody planned for.

Building systems that keep working when conditions change is closer to software engineering than to running a business, and most business owners have a business to run. The gap between a prototype that works and a system that works reliably, week after week, is where most of the trouble lives.

So this issue is about finding that gap and narrowing it, so that more business owners can build automations that hold up on their own.

The happy path

Engineers call the version of a process where everything goes as expected the happy path. Every field is filled in. The document arrives in the usual format. The customer asks for exactly the thing the system was built to handle.

A test is almost always a happy path, because it uses the input you imagined while building. That is why the first version works so convincingly, and why it tells you very little.

It is a bit like learning to drive on an empty road on a dry Sunday morning. Everything you learned is correct. It just has not met rain, darkness, or a truck pulling out without signalling yet.

When automations fail, the cause usually sits in one of five places.

1. Real data is messier than test data

Test data is clean because you chose it. Real data arrives however it arrives.

For a tax advisor processing receipts, that means photos taken at an angle, credit notes with negative amounts, invoices in a foreign currency, two invoices scanned into one file, and a supplier who changed its template overnight. Each of those is an ordinary change the system may not expect.

What helps: define what a valid input looks like, and check every item against it before the model sees anything. Whatever does not fit goes to a person, with a note explaining why. Keep a folder of the messiest real examples you can find, and test every change against it.

2. Nothing was built around the model

A recipe can taste just as good in your own kitchen as it does in a restaurant. What changes in a restaurant is everything around it: cooking the same dish two hundred times on a busy Saturday, when the usual supplier is out, with someone checking each plate before it leaves.

In an AI automation, the model is the recipe. The kitchen is everything around it, what engineers call the harness: how inputs reach the model, the format it has to answer in, what happens when an answer comes back in a different shape, retries when a service times out, and a record of what happened. Plenty of self-built automations are a prompt connected to a trigger with very little of that in place. They work until the model phrases something slightly differently one day, and the next step can no longer read it.

What helps: ask the model for output in a defined format, and check that format before anything downstream uses it. Add retries with a limit and sensible timeouts. Log every input and output. Keep versions of your prompts the way you would with code, and know which model version you are running.

3. The exceptions have nowhere to go

A booking agent for a small dental practice handles "I would like a check-up next week" perfectly. Then the real calls arrive. Someone in pain who needs to be seen today. A parent booking three children in one call. A patient who wants "the same as last time." The dentist is off sick and six appointments need moving.

A system that only knows the happy path handles each of those badly, and often confidently.

What helps: an explicit route to a person for anything outside the known cases, with the context attached so they do not start from scratch. Make "I am not sure" an acceptable answer, and treat it as the signal to hand over.

4. The business changed and the automation did not

An intake automation at a small law firm sorts enquiries by practice area and flags deadlines. It works for months. Then the firm adds a new practice area, a court changes the layout of its letters, or a client writes a deadline as "within two weeks of service" in place of a date. The automation keeps running, confidently, on assumptions that quietly stopped being true.

What helps: keep business rules somewhere the owner can read and edit them, such as a simple table, so a new practice area is a one-line change. Rules buried inside a prompt tend to be forgotten until they cause a problem. Give the automation one named owner who reviews it whenever the business changes.

5. It fails without making a sound

The worst failures are silent. A password expires. A connection stops sending data. A form gets redesigned and no longer passes anything on. Nothing throws an error, so nothing alerts anyone. The automation simply does less, and it goes unnoticed until someone asks why the numbers dropped.

What helps: alert on absence as well as on errors. If it normally handles twenty items a day and today it handled none, something should tell you. A five-minute weekly look at what it actually did catches more than you would expect.

Why this is hard when engineering is not your job

Most people can replace a light fitting. Wiring a building so it stays safe for twenty years, through extensions, renovations and the occasional power surge, is a trade people train for. Nobody thinks less of a homeowner for calling an electrician for that part.

AI has turned automation into the light fitting. What sits behind it is still the wiring.

The best results come from both halves working together. The business owner knows what matters: what counts as urgent, which deadlines are fatal, which documents the tax office will reject. The engineering brings the habits that keep it running when the inputs get messy. An automation built with only one of the two tends to be either the wrong thing done carefully, or the right thing done fragile.

Before you trust an automation to run on its own

If you are building these yourself, this is the list I would work through.

1. A folder of real, messy inputs, with every change tested against it.

2. A clear definition of valid input, checked before the model sees anything.

3. Output in a defined format, validated before the next step uses it.

4. A route to a person for anything uncertain, with the context attached.

5. Retries with limits, sensible timeouts, and a place where failed items wait instead of disappearing.

6. A log of every input and output.

7. Alerts for silence as well as errors, plus a short weekly review.

8. Business rules kept outside the prompt, with one named owner.

None of it is exotic. It tends to get skipped because the first version already works.

If you want one built properly for your business

If you would like to see what a reliable automation could look like in your own business, one that answers the enquiries you currently miss, keeps the customers who would otherwise drift away, or hands you back the hours that go into admin, book a call below. We will look at where automation would pay for itself first, and what it would take to make it hold up.

→ Book a call

Or reply and tell me about the last automation that broke on you. I read every reply.

What I'm Thinking About This Week

How much of software engineering was always about the cases nobody wanted to think about. The happy path was never the hard part. AI has made it almost free, which means the unglamorous work around it now makes most of the difference between something that runs and something that ran for a while.

Reply to this email with one of:

• What was the last automation that broke on you, and what broke it?

• If one of your automations stopped running today, how would you find out?

• Where do the rules of your automations live: somewhere you can read them, or inside a prompt?

P.S. The toolkit, in the order I would use it: Scout → Visibility Audit → GEO/AEO Audit Checklist → How to Get Cited by AI → SEO Strategy Playbook → Title & Meta Audit → Sovereign Idea Workflow. All free.

P.P.S. Know someone who built an automation over a weekend and has been fixing it ever since? Forward this. The list near the end is the useful part. They can subscribe at thesovereigntechnologist.com.

That’s all for this week.

See you next Thursday.