Automation That Sticks. Why Most Workflow Tools Break in Six Months.
The automation graveyard is full of workflows that worked at demo day. Here is what separates automation that lasts from automation that gets quietly turned off.
The six-month problem
A pattern repeats whenever a client brings us in to fix automation they built before finding us. The flow was running fine. Then someone renamed a spreadsheet column. Or the source API added a pagination parameter. Or a new hire started entering data in a slightly different format.
The automation broke. Nobody knew how to fix it. It was easier to go back to doing the work by hand.
This is not a tooling problem. It is a design problem. Automation that is brittle is not automation. It is a scheduled failure waiting for a trigger.
What makes automation fragile
Hard dependencies on format
Most flows built on Zapier, Make or ad-hoc scripts assume the data will look identical every time. A column named "Customer Name" is never renamed. A webhook payload never restructures. An email subject always matches the same regex.
Business data evolves. Schemas change. Formats drift. Automation designed around exact matches is designed to break the first time the business changes.
No visibility into failure
The second failure mode is silent. A step fails. Nothing happens. The record that should have been created was not created. The notification that should have fired did not fire. The report that should have been sent was not sent.
Three weeks later, someone notices an anomaly and spends a day tracing it back to an automation failure that happened quietly while everyone was shipping something else.
Built by the one person who understands it
The most dangerous automation is the automation built by the person who will eventually leave. When they do, nobody else knows what it touches, what it depends on, or how to fix it. It runs in the background until it either fails loudly or gets turned off.
What durable automation looks like
Defensive parsing, not exact matching
Automation that lasts tolerates variation. Field values get normalized before they are used. Column names are matched against an explicit mapping, not a hard-coded string. Input validation catches format drift and alerts a human instead of pushing bad data downstream.
Observable by default
Every automation we build logs what it received, what it did and what it produced. Failures send alerts with enough context to diagnose the problem without cracking open the code. Successes are queryable. If something goes wrong six months from now, the audit trail is already there.
Our internal AI DevOps engineer, Bin, runs a lot of the monitoring layer for these systems. When a pipeline starts drifting in cost, latency or success rate, Bin flags it to the team before the client notices. That feedback loop is the difference between automation that decays and automation that compounds.
Documented like infrastructure, because it is
We treat automation the same way we treat production code. Version control. README. Runbook. Owner. Anyone on the operations team can understand what a flow does, why it exists and what to do when it fails, without hunting down whoever built it first.
The automation we build
When WTM ships a workflow automation project, the discovery phase is not optional. It is where we find the edge cases that will break fragile flows and design around them. Inputs. Outputs. Dependencies. Failure modes. All mapped before the first integration is written.
Over a hundred products later, the same thing is true every time. Automation that runs quietly for three years is not impressive until you price what it replaced.
That is the bar.