You signed off on the automation eighteen months ago. Nobody has looked at it since. If it's still running, you got lucky. If it isn't, you probably don't know yet.
What actually makes an automation break
It is not the AI failing. It is a downstream dependency changing while nothing is watching.
The pitch for automation is always the same: build it once, and it runs forever. That was never true of software, and it is even less true of anything with a language model in the loop, because a model's output can shift slightly between runs on the exact same input. A rigid workflow expecting one specific format from that output will eventually get a variant it can't parse, and it fails.
That is the mechanical failure. The bigger one is organizational: this is the same lesson we cover in the engine, not random acts of marketing piece. An automation is not a purchase you make once. It is a system, and every system needs an owner, a feedback loop, and a maintenance cadence, or it degrades the moment its environment changes underneath it.
The system it depends on changes without warning
Third-party APIs and apps change pricing, fields, and features on their own schedule, not yours.
Most automations are held together by connections to other people's software, a CRM, an ad platform, a payment processor, a spreadsheet someone else edits. None of those vendors owe you advance notice before they rename a field, retire an endpoint, or move a feature behind a paywall. When that happens, the automation doesn't politely pause. It keeps running against a connection that no longer works the way it expects.
The failure that actually costs you money is the quiet one: a lead-routing workflow that starts silently dropping records because a CRM field got renamed, and nobody notices until someone asks why the sales team hasn't heard from a client in three weeks.
Nobody owns it after launch
A build with no named owner has no one checking it until it has already cost you something.
Marketing automation research keeps landing on the same point. "Marketing automation platforms, and now AI, don't fail," wrote Lisa Heay, Vice President of Business Operations at Heinz Marketing, in a piece on why orchestration, not more automation, is usually the actual fix. "They expose gaps in strategy, process, and alignment." An unowned automation is exactly that kind of gap made visible. An automation with a named owner gets checked. One without gets discovered, usually by the person it was supposed to help, at the worst possible moment.
This is the exact fear that shows up when a marketing lead is handed a vendor-built system instead of a team member: the automation was supposed to remove work, and instead it quietly became one more thing to babysit, except nobody told you that was the job.
It has no way to tell you it failed
Most automations fail silently. Without alerting, "working" and "broken" look identical from the outside.
A visible error is an inconvenience you can usually fix in an afternoon. A silent failure costs more, because nothing distinguishes a broken workflow from a working one until the downstream damage, a missed lead, a wrong invoice, surfaces on its own, often weeks later. This is a build decision, not bad luck: error handling and failure notifications have to be designed in from the start, the same way you'd design in the actual task the automation performs.
One useful contrast here: MarTech has argued that a lot of "broken" marketing automation isn't actually broken, it's overloaded, buried under more workflows than anyone can trace. That's a fair distinction, and worth extending: overloaded systems fail the same way unowned ones do, silently, because nobody can see the whole picture well enough to notice one piece slipping.
It was built for today's process, not next year's
The workflow gets brittle the moment the business changes and the automation does not.
An automation is a snapshot of how the business worked on the day it was built: which fields mattered, which steps happened in which order, which exceptions were rare enough to ignore. Every one of those assumptions has a shelf life. Add a new product line, change a pricing tier, hire a second person into a role that used to be one person's job, and the automation is now running against a business that no longer exists in the shape it was built for.
None of this is a reason to avoid automation. It's a reason to stop treating it as a one-off install. Gilbo.ai's own advice on this, after watching enough builds break, is to run a simple rhythm of review, refine, retest, and adjust, the same discipline you'd apply to any other system with a shelf life.
The questions that predict whether it'll still be running in 12 months
Before you sign off on an automation build, whether it's coming from an in-house team or an agency, these are the questions worth asking, the same questions you'd ask before hiring an agency in the first place:
- Who is the named owner of this automation after handover? Not a team. A person.
- What happens, and who gets told, the moment it stops working? If the honest answer is "nothing," that's your answer about how it'll fail.
- What's the maintenance cadence? A build date is not a maintenance plan.
- Which third-party dependencies could change without warning, and what's the fallback if they do?
- Has it been tested against a deliberately broken input, not just the input that works?
If a vendor can't answer these before you sign, that's the information. Not the pitch. The answers.
Treat an automation like the system it is, not a one-off purchase. It needs an owner, a way to fail loudly instead of silently, and a maintenance plan that assumes the world around it will keep changing, because it will. We've run this discipline across 9 years and 600+ clients, and the pattern holds regardless of the tool: the automations that are still running in 12 months are the ones somebody kept watching, not the ones that were built well once and left alone.
If you're not sure whether the automation you've got would survive an audit, tell us about your business.
↳ Frequently asked
01Why does AI automation break over time?
It breaks because the systems, data, and processes it depends on keep changing while the automation itself stays fixed. The AI component rarely causes the failure directly; a changed API field, a silently updated third-party app, or a business process that's moved on is the more common cause.
02Is it the AI that's failing, or something else?
Usually something else. Large language models can produce slightly different output on identical inputs, which breaks rigid downstream parsers, but the more common failure is a dependency change: a CRM field renamed, an integration deprecated, a pricing tier that removed a feature the automation relied on.
03How do I know if my automation is still working correctly?
Only if it's built to tell you. Without active error handling and alerting, a broken automation and a working one look identical from the outside until the downstream damage (a missed lead, a wrong invoice) surfaces on its own.
04Should I build marketing automation in-house or hire someone to build it?
Either can work, but ownership matters more than who builds it. An in-house build with no named maintainer fails the same way an agency build with no handover plan does. The build source matters less than whether someone is accountable for it after launch.
05What's the difference between an automation being "broken" and being "overloaded"?
A broken automation has stopped doing its job. An overloaded one is still running, but has accumulated so many connected workflows that nobody can trace what happens when one piece changes, so it fails the same way an unowned build does: quietly, and for reasons nobody can immediately locate.
06How often should an automation actually be checked or maintained?
There's no universal number, but "never after launch" is the wrong answer every time. The right cadence depends on how often the systems it touches change; anything that connects to a third-party API should be checked whenever that vendor ships a change, not on a fixed calendar alone.