Nine Production Automations Have 31 Endings. Fewer Than Half Are the Happy Path

Almost nobody publishes the architecture of the automations they deliver. The usual reason is that the decision logic feels like the thing you are being paid for, so giving it away seems foolish.

The consequence is that there is very little public evidence about what a production automation actually looks like. Plenty of templates, plenty of demos, almost no anatomy.

We publish ours. Nine delivered systems are on this site as full teardowns: every intake channel, every branch, and the condition that fires it, transcribed from the delivered workflow rather than simplified for presentation. Which means we can do something unusual, and something anybody can repeat: count them.

The corpus

Nine systems, in nine different sectors, containing 139 nodes and 148 edges between them.

Every figure below is computed from those nine graphs. If you think a count is wrong, the data is one click away and you can recount it.

They fan out, they do not funnel

The mental model almost everyone brings to automation is a funnel. Several things come in at the top, the system processes them, one clean output comes out of the bottom.

The corpus says the opposite.

15 ways in. 31 ways out. Roughly two exits for every entrance, and seven of the nine systems have more endings than beginnings.

The one system that does not fan out, the B2B lead pipeline with a single entrance and a single exit, is the exception that makes the point: it is a narrow pipeline whose whole job is to get one kind of record into one destination without creating a duplicate. Everything that handles real-world input branches.

This is not an aesthetic observation. It is a scoping one. A specification that describes what happens when things go well is describing roughly one exit out of three.

Fewer than half the endings are the happy path

This is the finding I did not expect, and it is the one worth taking away.

We classified all 31 endings by what they actually represent:

More than half of what these systems do is not the thing they were built to do.

The eleven deliberate stops are worth reading as a list, because they are the part of an automation nobody writes into a proposal: Held for revision. Not viable. Fallback returned. Cold pool. Exits, nothing changed. Stored, base unchanged. Rejected. Held on watchlist. Front-desk task. No-show risk flag. Back to the card.

Every one of those is a case where the correct behaviour is to not proceed. A system that lacks them does not become simpler. It becomes a system that does the wrong thing confidently when reality fails to match the brief.

The five self-maintenance endings are the other quiet category: vector stores being updated, score histories being appended, records retained for audit. Work the system does on itself so that it keeps working, which never appears in the pitch and always appears in the build.

Decisions are a small minority of the structure

If you read automation marketing, you would think the model making decisions is most of the product.

Across 139 nodes:

• 64 are plain actions (46%)
• 31 are terminals
• 21 are decisions (15%)
• 15 are intake
• 8 are orchestration

The decision layer is about a sixth of the graph. And when we went through those 21 decision points individually in an earlier analysis, ten turned out to be deterministic rules, three were human on purpose and one was retrieval. Six were genuine judgment calls, and the twenty-first depends on image handling we could not verify, so we left it uncounted.

That is not an argument against using models. It is an argument that the engineering around the model is most of the work, and that a budget which treats the model as the project is mis-shaped from the start. It is also the same conclusion we reached from the other direction in why most AI agents never reach production.

These are not trigger-and-action scripts

Median depth is 10 stages, with a range of 6 to 12. Node counts run from 8 to 21.

The depth does not come from the main path being long. It comes from the branches: the cases where a value is missing, a match is ambiguous, a document is unverifiable, or a person has to sign off. The happy path through most of these systems is short. The system is large because of everything else.

One spine and a very long tail

47 distinct tools appear across the nine systems, and 57% of them appear in exactly one node.

Meanwhile n8n alone accounts for 19% of all nodes, because it is doing the routing almost everywhere. Airtable is next at 12 nodes, then GoHighLevel at 11 and Zoho CRM at 8.

So the real shape is one orchestration spine plus a long tail of tools that each do exactly one thing: a registry lookup, a transcription, a vision check, a video render, a crawl.

That tail is an argument against consolidation. A platform that promises to replace all 47 is offering to replace the easy part, because the tail exists precisely because each of those tools is the best available answer to one narrow problem.

What we would change about how you scope one

Three things follow directly from the counts.

Budget for the endings. If roughly half of a delivered system is refusals, holds, escalations and self-maintenance, then a scope covering only the successful path covers less than half the build. The most productive early question is not what happens when it works. It is what should happen when the input is ambiguous, when a human has to approve, and when the right answer is to do nothing.

Do not model a rule. Ten of the 21 decision points in this corpus are thresholds, exact matches, status lookups and checksums. Those execute in under a millisecond, cost nothing and are auditable. Putting a model behind one makes it slower, dearer and less predictable.

Expect the tail. If a proposal names three tools, it is either a simpler problem than this corpus, or the tail has not been discovered yet. Usually the second.

What this is not

Worth being explicit about the limits, because research with no stated limits is marketing.

Nine systems is a small corpus. These are directional findings, not population statistics.

They are all ours. One studio, one set of habits, one way of drawing a graph. A different team would produce different node counts for the same work, and our classification of what counts as a decision or a terminal is a convention rather than a law.

They are not a random sample. They are the delivered systems whose workflow source was detailed enough to transcribe honestly. Two further delivered systems are deliberately absent because their source documents carry block diagrams rather than per-edge conditions, and inventing the decision logic to fill the gap would have made this corpus worse.

And the classification in the endings table involves judgment. You may think Retained for audit is a delivered outcome rather than self-maintenance. That is a reasonable disagreement, it moves the headline by a few percentage points, and you can check it yourself, which is the whole point of publishing the graphs.

Why we publish these at all

A screenshot proves nothing. Anyone can show a dashboard.

A branch table showing every condition that fires proves somebody thought about the cases, and it lets a prospective client check the thinking rather than take our word for it. It also produces the occasional uncomfortable finding, like discovering that the decision layer we sell is 15% of the structure, and publishing that anyway.

All nine teardowns are public, with no client names and no measured figures, because the decision logic is the part worth showing. If you want the same treatment applied to a workflow of yours, tell us what it has to handle and book a discovery call. Two platforms carry most of this work, so we describe them separately: our n8n automation agency page and our GoHighLevel developers page.

All figures computed on 23 September 2026 from the nine system graphs published at /services/ai-automation/systems. Node kinds, stage counts and edge conditions are taken from the same data that renders those pages, so the counts and the diagrams cannot drift apart.