Automation projects rarely fail with a bang. They fail quietly — someone stops trusting the output, starts double-checking it manually, and within a few months the system is switched off and nobody mentions it again.
Here are the nine reasons that happens, in roughly the order they cost the most.
1. Automating a broken process
This is the expensive one, because you only find out after the build.
If the underlying process is wrong — the approval step everyone skips, the field nobody fills in correctly, the rule that has three undocumented exceptions — automation does not fix it. It executes the broken version faster and more consistently, and now the errors arrive at scale.
The fix: map the process on paper first. If three people describe it differently, you do not have a process yet. Fix that before writing anything.
2. Building for the happy path
In testing, every form is complete, every API responds, every name is spelled simply. In production, a field is blank, a customer's surname contains an apostrophe that breaks a query, and a service times out on Tuesday afternoon.
The fix: for every step, ask what happens if the input is missing, malformed or duplicated, and if the service is slow or down. Add a branch for each answer that matters. This roughly doubles the build time and roughly eliminates the support burden.
3. No human escape hatch
Every automated system meets a case it should not handle. Without a defined route to a human, it will do something — and that something is usually worse than doing nothing.
The fix: build the escalation path first, before the clever parts. A rule that says "if confidence is low, or the amount exceeds X, or the customer used these words, route to a person" makes the whole system safe to deploy.
Especially true for AI steps. An AI model with no escalation option will produce a confident answer rather than admit it does not know, because answering is the only action available to it.
4. Trusting AI output blindly
An AI step returns text. That text goes straight into an email, a database field, or a customer-facing message. Nobody checks the shape of it.
Then one day the model returns a preamble before the JSON, or an explanation instead of the value, and the downstream step writes nonsense into your records.
The fix: validate every AI output before using it. Check it parses. Check required fields exist. Check numbers are in a plausible range. If validation fails, retry once, then escalate — never pass unchecked model output into a system of record.
5. Ignoring idempotency
The unglamorous one that causes the most embarrassing failures.
A webhook fires twice — networks retry, users double-click, services resend. If your workflow is not idempotent, the customer gets two invoices, or two welcome emails, or is charged twice.
The fix: give every incoming event an identifier, record the ones you have processed, and skip duplicates. It is fifteen minutes of work and it prevents the class of bug that damages trust fastest.
6. Hard-coding everything
The email address, the price threshold, the API key, the recipient list — typed directly into the workflow in eleven different places.
Six months later something changes and you are hunting through nodes hoping you found all of them. Worse, if credentials are pasted inline, they end up in exports and screenshots.
The fix: credentials in the platform's credential store, never inline. Business values — thresholds, addresses, templates — in one place at the top, or in a small config table the client can edit without touching the workflow.
7. No monitoring
The system runs perfectly for six weeks. In week seven an API changes and it starts failing silently. Nobody notices until a customer complains a month later.
Silent failure is worse than loud failure, because the business kept making decisions on data that stopped updating.
The fix: two things. An alert when a run fails — to a channel a human actually watches, not an inbox nobody opens. And a periodic heartbeat confirming it is still running, so silence itself becomes a signal.
8. Reaching for an agent too early
An agent is impressive and occasionally necessary. It is also more expensive per run, harder to debug, and non-deterministic — meaning the same input can produce different behaviour.
Most processes that get built as agents are, when you actually map them, a fixed sequence of steps.
The fix: if you can draw it as a flowchart and the arrows never change, build a workflow with an AI step in it. Save agents for where the next action genuinely varies based on what was found.
9. Building it on your own accounts
This one is aimed at anyone building for a client, and at any client hiring a builder.
If the system runs on the contractor's platform account, using the contractor's API keys, on the contractor's server — the client does not own it. When the relationship ends, so does the system.
The fix: build on the client's infrastructure and accounts from day one. Hand over documentation. It makes the relationship healthier, because the client stays for the quality of the work rather than because leaving is painful.
The pattern underneath
Almost every item on this list is the same mistake in different clothing: optimising for the demo instead of the third month.
A demo needs to work once, with good data, while someone is watching. A production system needs to work every time, with whatever data arrives, when nobody is watching. The gap between those two is where the actual engineering lives — and it is most of the work.