Building automations that don't quietly breakBuilding automations that don't quietly break

The failure mode nobody warns you about isn't the automation that crashes. It's the one that stops running in March and nobody notices until July, when someone asks why the pipeline report looks thin.

Every workflow I hand over gets the same five additions, regardless of platform. They take about twenty minutes and they are the difference between a demo and a system.

1. An error branch that talks to a human

Every flow gets an error handler that posts to a Slack channel or an email alias with the workflow name, the failing step, and the payload that caused it. Not a log file someone would have to think to check.

2. Retries with backoff — but bounded

Third-party APIs fail transiently. Three retries with exponential backoff handles the vast majority. What matters is that attempt four gives up loudly instead of retrying forever and burning your operation quota.

3. Idempotency on anything that writes

If a workflow can create a record, it can create it twice. Dedupe on a stable external key before the write, not after. This is the single most common cause of 'why do we have four of this lead'.

4. A human gate on anything AI generates

AI drafting is genuinely useful for follow-ups, summaries and classification. Fully autonomous AI sending client-facing email is a reputational risk with no upside. Draft, queue, approve, send.

5. A heartbeat

A scheduled workflow that hasn't run is invisible. A daily heartbeat that pings a monitor makes absence loud. This is the one people skip and the one that catches the March-to-July failure.

Automation is not about removing humans. It's about removing the parts of the job that a human does worse than a script — and keeping them exactly where judgement is required.