A flow only runs the decisions you already made.

Give n8n its due first, because the argument only works if you do. It is a genuinely capable tool. You get a visual canvas wired to more than a thousand integrations, and you can self-host the whole thing on your own machine with your own credentials, which is a real advantage over closed boxes like Zapier and Make. You can drop into JavaScript or Python when a node won’t do what you need. It is source-available under a fair-code licence rather than fully open source, a distinction n8n itself is careful about, and the practical point holds either way: you can read it and run it yourself. For moving data from one system to another on a schedule or a webhook, it is excellent, and it will keep running for years.

So the case against it is not that it is badly built or that it can’t do the job. It is that the job it does best has a ceiling, and the ceiling is the shape of the tool, not the height of the learning curve.

Where the flow stops

Take something n8n is genuinely good at. A lead fills out your contact form. The flow catches the webhook, enriches the company domain, writes the record to your CRM, tags the lead “priority” if the headcount clears a threshold, drops a note in the right Slack channel, then fires a templated thank-you. That is plumbing done right: reliable, and it never forgets a step. Build it once and it earns its keep every morning.

Now the acknowledgement. Most of the time the template is fine. But this particular “lead” is an existing customer asking about a renewal, and the generic new-prospect reply is going to read as if nobody knows who they are. Or they named a competitor in the notes, and there is a sharper thing to say back. Or the message is plainly a real buying signal rather than a tyre-kicker, and it deserves a person within the hour instead of a form response. “Reply the way this situation actually calls for” is not a threshold you can set anywhere on the canvas. It is a judgment.

You have two moves in n8n, and both of them make the point. You add another branch, then another, one rule for each case you manage to think of, and you maintain that growing thicket forever while still only covering the situations you anticipated. Or you pull the interesting leads back out of the flow and handle them by hand. Either way the machine automated the dull sixty percent and returned you the forty percent that actually needed a decision. That is the second job every one of these builders quietly hands you, and it deserves an essay of its own; the narrow point here is when the bill comes due, which is the exact moment a judgment is required.

Wire in the AI node, says the power user

Here is where someone who knows n8n pushes back, and they are right to. n8n has an AI Agent node now. Give it a model, feed it the CRM context, let it write the reply. And yes, that closes part of the gap. But look at what you are actually doing. You are assembling and maintaining an agent as one component inside a flow you still own, tuning its prompt, wiring its tools, catching its failures, versioning the whole thing when the model underneath it changes. The judgment moved into a box on your canvas. The canvas is still yours to keep alive. You did not stop being the operator; you handed the operator a cleverer part to operate.

That is the wall, and getting good at n8n does not move it. Fluency in expressions and JSON and error handling makes you faster at building the machine. It buys you a taller machine standing in front of the same gap. The reviewers who say the learning curve is steep but you’ll get there if you put the hours in are conceding the case without noticing it: the hours buy you a bigger apparatus that still cannot make the call that mattered.

Describe the outcome instead

There is a different shape to this, and it starts by giving up the canvas. You describe the outcome and hand off the how. “Watch the contact form. Qualify leads the way I would, write a reply that fits who the person actually is, and flag anything you’re unsure about before it goes out.” No canvas. Nothing to keep maintained. The judgment is delegated the way you would delegate it to a capable colleague, with a checkpoint on the part that carries real risk. That is the thesis behind be/brief: you stay the one who decides, and the machine you were tending stops being a machine you tend.

None of this is a hunch about tooling fatigue. The research on low-code development keeps landing in the same place: maintenance and debugging show up as their own distinct burden, and practitioners keep hitting the point where a project outgrows the platform it was built on. The flow was never free. You pay for it in the branches you keep adding and the one call it still can’t make for you.