Why automations fail in week six: 6 patterns to prevent it

Around client automation number 40, I built a lead-routing flow for a marketing agency. It routed each lead by service type, assigned it to the right account manager and triggered a personalised follow-up. It was a solid build, and the client was happy.

Six weeks later it broke. A lead came in from a source that the filter was not designed for. The lead routed nowhere. There was no alert and no fallback, only a lost contact and a client who asked why nobody had followed up.

When I went in to fix it, I found no missed technical step. I had missed a design question that I did not know to ask: what happens to inputs this flow does not recognise? That was not an n8n problem. It was a pattern problem. I did not know what to look for, because I had no name for the type of automation I was building.

Every automation fits one of six architectural patterns: the Trigger-Route, the Filter-Fan, the Collector, the Loop, the Transformer and the Watcher. Each pattern has its own failure modes and its own pre-build checks. Name the pattern before you build. Then you know which design questions to answer, and the automation stays reliable after week one.

Why "map the happy path" is not enough

The usual build process finds the obvious cases and misses the questions that decide reliability. Most builders handle a new brief the same way: they read the requirements, map the happy path, build the flow, test it and ship it. That process works for the obvious cases.

The usual process does not surface the non-obvious questions. Those questions decide whether the automation still works in week six, not only in week one:

• What happens when the input is malformed?
• What is the exit condition if the loop never resolves?
• What does the system do with data it was not designed to handle?

Without a pattern framework, these questions stay hidden until something breaks. You do not know to ask them, because you have no name for the type of automation you are building. Different types have completely different failure modes.

What does building without a pattern cost?

The main cost is the quality of the build, not the hours. An automation designed without a known pattern handles the happy path well and everything else poorly. It works in testing and in the first few weeks. Then an edge case arrives: an unexpected input, a loop that never exits, a source that returns zero records. The automation fails silently, or it produces wrong output that nobody catches until the damage is downstream.

Across 2,500+ builds, the automations that needed the most rework were not the complex ones. They were the simple ones where the builder did not ask the right structural questions at the start. Those questions are not hard to answer. Without a pattern framework, they are hard to think of.

The 6 automation patterns and what to check in each one

By automation number 100, I had catalogued enough failures to see the pattern under each one. Across 2,500+ builds for agencies, SaaS companies, logistics operators and consultancies, every build mapped to one of six architectural types. Each type has its own design questions, its own failure modes and its own pre-build checklist. Name the pattern first. Then you know what to look for.

Pattern 1: The Trigger-Route. A Trigger-Route is one event, one linear path and one outcome. Use it for notifications, confirmations and data syncs. Example: a client books a meeting, the automation creates a CRM record, sends a confirmation and notifies the account manager in Slack. Best practice: add a failure alert at the last step. If the final action does not fire, you want a Slack message to a named owner, not a silent gap in your CRM. Trigger-Routes fail silently more often than any other pattern.

Pattern 2: The Filter-Fan. A Filter-Fan sends one input to one of several conditional exits, based on the input's properties. It is the most common pattern in service business automation, roughly 60% of everything you will build. Example: an inbound lead is classified by service interest, then routed to the right rep, or added to a nurture sequence if it is not ready. Best practice: always build an "unclassified" exit. This branch catches anything the filter did not expect. Every Filter-Fan without a catch-all eventually drops records silently. The unclassified branch must alert a human, not discard the record.

Pattern 3: The Collector. A Collector merges several data streams into one output before any action happens. Example: sales data from three regional CRMs is merged into one master sheet, and the CEO gets a single summary email every Monday at 7am. Best practice: validate the record count before the output fires. If you merge three sources and one returns zero records unexpectedly, flag the anomaly. Do not send a summary built on incomplete data.

Pattern 4: The Loop. A Loop repeats until a condition is met and the loop is explicitly broken. It is the backbone of follow-up sequences, retry logic and escalation flows. Example: an invoice is sent. If it is unpaid at day 7, a reminder goes out. If it is unpaid at day 14, a second reminder goes out. If it is unpaid at day 21, the automation flags it to accounts and the loop exits. Best practice: always define a hard exit condition in addition to the primary one. "Loop until paid" is incomplete. You also need "exit after N attempts regardless." An infinite loop does not throw an error. It runs until your operation count reaches zero.

Pattern 5: The Transformer. A Transformer takes raw input, reshapes it (most often with an AI step) and outputs something structured that the next system can use. The reliable architecture for this pattern is the AI Sandwich. Automation delivers clean, consistent data to the AI (the Bottom Bun). The AI does one specific job (the Meat). Automation catches and routes the output (the Top Bun). Humans review results; they do not move data. Example: a client fills in a brief form, the AI extracts the key requirements into a structured project spec, and the automation posts the spec to ClickUp with the right template. Best practice: treat the AI prompt as a typed function, not a conversation. Define the exact output schema before you write the prompt: JSON field names, data types and character limits. An AI step that returns freeform text into an n8n router is a reliability problem that waits for its first edge case.

Pattern 6: The Watcher. A Watcher is a passive monitor that runs continuously and fires only when a threshold, anomaly or condition is crossed. You do not see it when everything works, and you need it when something does not. Example: the automation checks a revenue dashboard every 4 hours. When daily bookings drop 20% below baseline, it sends the founder an alert with the last 48 hours of data attached. Best practice: set the check frequency by how fast you can act, not by how fast the problem develops. A check every 15 minutes is useless if your response time is same-day. Check hourly and act daily. Always include the data that triggered the alert in the message. A notification that says only "anomaly detected" is noise.

The remaining 10% of builds are almost always a Transformer that feeds a Filter-Fan. The AI reshapes the input, then the automation routes the reshaped output by type.

How to use the patterns before you build

Classify the automation before you open the builder. Classification takes five minutes, not three hours, and it gives you the design questions for that pattern before the build, not after the first failure. For a longer method, the Automation Architecture Guide walks through how to name the pattern before you build.

1. Name the pattern. Decide which of the six types the automation is. If an AI step reshapes the input and the result is then routed, it is a Transformer that feeds a Filter-Fan.
2. List the pattern's failure modes. Use the table above. Each pattern fails in its own way, so each one needs its own checks.
3. Build the checks into the design. Add the failure alert, the unclassified exit, the record-count check, the hard loop exit, the output schema or the alert data before you build the happy path.
4. Review other automations with the same lens. When you know what a complete version of a pattern looks like, you see what is missing in someone else's build. You do not need to hunt for bugs.

Bottom line

Most automation fragility does not come from technical mistakes. It comes from design questions that nobody asked. The pattern gives you the question list, and the build answers it.

For years I built flows without knowing what type of thing I was building. Once you have the names, you cannot un-see the gaps they show.

P.S. If you are still choosing a platform for these builds, read Zapier vs Make vs n8n first.

Build a calmer business,Yuri

Frequently asked questions

Why do business automations break after a few weeks?

Most automations break because nobody asked the right design questions before the build, not because of technical mistakes. A flow built only for the happy path works in testing and in the first weeks. Then an edge case arrives, such as an unexpected input, a loop that never exits or a source that returns zero records, and the automation fails silently or sends wrong output.

What are the six automation patterns?

The six automation patterns are the Trigger-Route (one event, one linear path), the Filter-Fan (one input, many conditional exits), the Collector (many data streams merged into one output), the Loop (repeat until a condition is met), the Transformer (raw input reshaped, often by AI, into structured output) and the Watcher (a continuous monitor that fires when a threshold is crossed).

What is the most common automation pattern in a service business?

The Filter-Fan is the most common pattern in service business automation, at roughly 60% of builds. One input, such as an inbound lead, goes to one of several exits based on its properties. Every Filter-Fan needs an "unclassified" exit that catches unexpected records and alerts a human. Without that catch-all branch, the Filter-Fan eventually drops records silently.

How do I stop an automation loop from running forever?

Give every Loop automation two exit conditions. The first is the primary condition, for example "exit when the invoice is paid". The second is a hard limit, for example "exit after N attempts regardless". An infinite loop does not throw an error. It keeps running until it uses up your operation count, so the hard limit is what stops it.

How should an AI step be built inside an automation?

Treat the AI prompt in an automation as a typed function, not a conversation. Define the exact output schema before you write the prompt: JSON field names, data types and character limits. An AI step that returns freeform text into a router, for example in n8n, will fail at the first edge case. Automation should deliver clean input to the AI and route its output.