Before You Build the Workflow, Understand the Process

I’m writing this from Bangkok, where I’ve been teaching a course at Harbour.Space University on Building AI agents and automation workflows with no code, or as close to no code as you can get. The students are sharp. They came in expecting to learn tools. What they’re leaving with is something harder to package but considerably more useful: a critical mind about when and how to build automations in the first place.

That shift in thinking is what this article is about.

The thing nobody selling workflows wants you to know

There is a cottage industry on YouTube, LinkedIn, and every automation platform marketplace built on one simple promise: here is a template, install it, and watch your business run itself.

The people selling these workflows are not necessarily dishonest. Some of them genuinely believe in what they’re offering. But most of them have never had to account for results at the end of a client engagement. They’ve never had to explain to a business owner why the beautiful 47-node Make scenario they sold them is eating €800 a month in API credits and producing outputs that nobody acts on.

I have. At sendXmail and ZOPPLY, my agencies, I have to answer for that. The automations we build have to demonstrate a return, or we haven’t done our job. That accountability changes how you think about what to build and, more importantly, what not to build.

Bill Gates wrote in Business @ the Speed of Thought (1999):

“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”

That was written 26 years ago about enterprise software. It applies, without a single word changed, to n8n workflows in 2026.

You cannot automate what you do not understand

Michael Hammer published “Reengineering Work: Don’t Automate, Obliterate” in Harvard Business Review in 1990. The central argument: companies use technology to mechanise old ways of doing business, embedding outdated processes in silicon instead of questioning whether those processes should exist at all. His most quoted line is the bluntest: “Automating a mess yields an automated mess.”

Thirty-six years later, the automation industry is selling pre-made messes at scale.

Here is the pattern I see repeatedly, both in clients who approach my agencies and in the students who arrive at a course like the one I’m running in Bangkok. Someone sees a workflow on a YouTube thumbnail. The node graph looks impressive. They download the template, spend three hours debugging API connections, and eventually get it running. Then they ask: what does this actually do for my business? Often the answer is unclear, because the workflow was designed for someone else’s process, in someone else’s context, solving someone else’s problem.

The correct order is the reverse. You define the problem, you map the process, you understand what is actually happening today, and only then do you decide whether automation is warranted and what form it should take. The template comes last, if it comes at all.

Keep in mind that I’m not referring to a technical argument. It is, in fact, a process argument, and it is much older than AI.

What “mapping the process” actually means

I am not suggesting everyone needs to become a certified Six Sigma practitioner. But there are tools from process management that every person building automations should at least understand, because they force the right questions before a single node gets placed.

A SIPOC diagram (Suppliers, Inputs, Process, Outputs, Customers) is perhaps the most useful of these. It is a single table that maps where the inputs to a process come from, what the process actually does with them, what it produces, and who receives those outputs. If your team cannot fill in a SIPOC for the process you are about to automate, you are not ready to automate it. You do not yet agree on what the process is.

The “as-is” versus “to-be” distinction matters equally. Teams designing automated workflows almost always jump straight to the imagined future state without documenting the messy current reality. The agent then gets built for a process that does not exist. It handles the clean version of reality, not the one with exceptions, edge cases, and the three things your most experienced team member handles in their head without telling anyone.

Swim lane diagrams, which show who does what across an organisational boundary, are particularly useful when an automation crosses departments or systems. Hidden handoffs are where automated processes most often fail silently. Mapping them by hand, even roughly, forces those handoffs to be visible before the code touches them.

The medium matters too. In my Bangkok sessions, I make students draw their workflows on paper before they open any tool. There is a reason Toyota’s value stream maps were described by the Lean Enterprise Institute as “often drawn on scrap paper.” The constraint of analogue mapping forces abstraction.

You cannot fit 47 nodes on a Post-it, so you are forced to think about what actually matters. Digital tools, on the other hand, make it frictionless to keep adding complexity, because there is no physical cost to adding another node, another branch, another agent call.

That frictionlessness is precisely the problem.

The complexity trap, and who profits from it

Gartner predicted in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027. Their analyst described the current landscape plainly: most projects are early-stage experiments driven by hype, often misapplied, which “blinds organisations to the real cost and complexity of deploying AI agents at scale.”

EY’s research on RPA, the robotic process automation wave that preceded the current AI agent moment, found that 30 to 50% of initial automation projects failed. Forrester found that 45% of firms experienced bot breakage weekly or more often. The Deloitte Global RPA Survey found that only 3% of organisations had successfully scaled to 50 or more bots. These are not figures about bad technology, but about organisations automating processes they did not understand.

The AI agent wave is reproducing every one of these failures, just faster and with more expensive API calls.

What makes this cycle worse now is the market of workflow sellers who have no accountability for outcomes. The economics of selling automation templates or “AI automation agency” services on YouTube are straightforward: produce content that looks impressive, offer a course or a template library, collect the subscription, and move on.

Nobody tracks whether the 23-node lead qualification agent actually qualifies leads.
Nobody measures the customer service bot’s effect on satisfaction scores.
Nobody audits the token spend against the business value produced.

At my agencies, we track all of that. An automation that costs more to run than it saves in labour is a liability, instead of an asset. Most of the templates circulating on automation marketplaces have never been subjected to that test.

MindStudio described this phenomenon as “setup porn.” The visual complexity of the workflow becomes the value proposition, not what the workflow produces. Their diagnostic question is one I have started using with my students: if you removed this component, would the output break? If not, it should not be there yet. Complexity that does not directly serve the output is waste, and waste in a workflow compounds with every execution.

Before you automate, eliminate

The most useful decision sequence I have found puts automation in exactly the right position: third.

You begin by asking whether the task should exist at all. Peter Drucker put it directly:

“There is nothing so useless as doing efficiently that which should not be done at all.”

A considerable number of business tasks survive because they have always been done, and nobody has questioned them. An automated version of a useless task is still useless, but now it runs 24 hours a day.

If the task survives that question, you simplify it before you touch any tooling.

Can it be standardised?
Can exceptions be reduced?
Can the inputs be made more consistent?

A process with high variance, many exceptions, and undocumented steps is a poor candidate for automation regardless of which platform you use. Rules-based systems cannot tolerate the workarounds and side-channels that experienced humans use to keep broken processes functioning.

Only after elimination and simplification does automation enter the picture. And even then, the question is not “which template fits closest?” but “what is the simplest automation that solves this specific problem?”

Anthropic’s own guidance on building effective agents is, given their commercial interest in you using more of their models, notably restrained on this point: “When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.”

That is the company that makes Claude telling you that you might not need an agent. It is worth taking seriously.

The cost of not thinking before you build

There is a concrete, financial dimension to this argument that rarely gets discussed in workflow tutorials.

A developer writing in April 2026 described what happened when he scaled his AI agent from a proof of concept to production: “$400 in January. $1,100 in February. By March, it was knocking on $4,000, for a product that was making maybe a tenth of that in revenue.” The root cause was a design failure, not so much a technology failure. He was passing the entire conversation history into every step of the agent. Every step. The fix was not a better model, per se, but understanding what the process actually required.

His conclusion lands precisely on what I teach: “Cost optimisation is not a technical problem, but a clarity problem.”

Model pricing matters here in ways that tutorials rarely address. Using Claude Opus when Haiku would suffice costs 25 times more per output token. Using a frontier model for a task that a simple conditional statement could handle is not sophistication, it is waste. The discipline of asking “does this step actually need an LLM?” before adding one to a workflow is not a beginner question, but, in fact, the most important question, and it should be answered before you build, not after your billing statement arrives.

Anthropic’s architectural guidance makes this explicit: prompt chaining, routing between models by task complexity, and parallelisation should all be exhausted before you reach for a fully agentic system. For many applications, a single, well-structured LLM call with good context is sufficient. An agent that spins up sub-agents to do what a conditional statement could do is not impressive engineering, but expensive confusion.

What my Bangkok students are learning

The shift I see happening in the Harbour.Space classroom is about sequence. Students arrive wanting to know which nodes to connect.

They leave asking different questions:

What is the process I am trying to improve?
Does it currently work?
How often does it run?
What breaks it?
How much does the failure cost?
What would a 10% improvement be worth, in hours or euros?

Those questions do not have answers in any template. They require sitting with the business, often doing the process manually a few times, and building a genuine understanding of the work before deciding how to change it. Paul Graham’s “Do Things That Don’t Scale” is the startup canon on this, but the logic applies directly to automation design: do the process manually until it hurts, then automate the bottleneck. Not the whole thing. The bottleneck.

Eliyahu Goldratt made this argument in manufacturing terms in 1984: an hour saved at a non-bottleneck is a mirage. Automating a step that is not the constraint does nothing to throughput. It just makes that step faster while everything backs up somewhere else. Most automation projects ignore this entirely, because it requires understanding the process well enough to locate the actual constraint, and that understanding takes time and observation that a YouTube template cannot provide.

A word on what the market is actually selling

I want to be direct about something, because I think it matters for anyone considering buying automation services or courses.

A large part of the AI automation market is operating on a model where the product is the appearance of capability rather than the delivery of results. Workflows that look complex in a screenshot. Agent architectures that require four services and three webhooks to do something a spreadsheet formula would handle. “AI-powered” solutions that are, on inspection, an LLM asked to extract information that could be parsed with a regular expression.

The practitioners building these things are not always aware that they are building waste. Many of them have genuine enthusiasm and some technical skill. What they lack is accountability. They build, they demo, they move on. There is no moment of reckoning at the end of the engagement where they have to show that the investment produced a return.

That moment exists in my work. It exists in most consulting relationships where results, not deliverables, are what get measured. And the discipline that comes from that accountability changes everything about how you approach automation design. You start with the question nobody in the template marketplace is asking: should we build this at all?

If the answer is yes, you map it by hand first. You run it manually. You measure the baseline. You identify where the friction actually is. Then, and only then, do you decide what to build, with what tools, at what level of complexity.

That is the kind of critical thinking that takes about 30 minutes of honest reflection before you open any platform. The problem is that 30 minutes of reflection does not make a good YouTube thumbnail.

The question worth sitting with

The students in Bangkok are getting something that a template library cannot give them: the habit of asking whether the complexity serves the outcome, or whether the complexity is the point.

Gartner, EY, Forrester, and Anthropic all say the same thing from different angles. Start simple. Understand the process before you encode it. Measure the result. Add complexity only when measurement justifies it.

The market will keep selling you the opposite. Your job is to notice when it is happening.

So before you install that template: can you draw the workflow on a piece of paper, walk a colleague through it, and have them execute it manually without any tooling? If not, you are not ready to automate it. You are ready to understand it.

That is where the work starts. Everything else is just nodes.