Is the workflow dead? No, it changed jobs.

Two stances clash, and both are wrong. The first wants to agentify everything: hand every task to an agent because that is the era we live in. The second wants to keep everything in workflow: refuse the agent because it is unpredictable. The first pays dearly and loses control; the second stays rigid and breaks at the first unforeseen case.

Between the two, there is no soft compromise. There is a decision: which part of a flow deserves a deterministic automation, which part deserves an agent. It is this decision, not the tool, that makes the difference.

A workflow does not think, and that is precisely its strength. When a task is predictable, repetitive, high-volume and low-ambiguity, it is unbeatable: fast, cheap, traceable, no surprises. You know exactly what is going to happen, on every run, for every input.

Receiving a form and creating a contact record, triggering a confirmation email, syncing two databases, routing a notification: these actions do not need an agent. Putting a language model in the middle of them means adding cost, latency and a chance of error where a simple condition was enough.

Determinism is not technological lag, it is a guarantee. In a serious system, you want the maximum of guaranteed actions and the minimum of uncertain ones.

The agent begins where the workflow stops: when you have to judge, adapt, understand an ambiguous situation. Read a poorly worded message and extract its intent. Choose a path that had not been planned. Reformulate, synthesize, hold a conversation that does not follow a script.

A conditional workflow handles ten cases if you wrote the ten branches. An agent handles the eleventh, the one you had not anticipated. This is exactly what the older automations lacked: they broke at the first off-script case, and you spent your time adding branches to catch up with reality.

But this flexibility has a price: cost per call, latency, variability. You spend it only where it genuinely creates value.

So the subject is never "n8n or agent", "Make or language model". The subject is: where to place the boundary between the deterministic and the agentic within the same system, and who decides on that boundary. It is a question of architecture, not of fashion.

And it is also, above all, a question of cost. A repetitive action moved into agentic is a bill that swells without you noticing. A complex judgment left to a rigid workflow is a system that breaks and that you keep patching up. Placing the boundary in the right spot means arbitrating between the cheap guarantee of the deterministic and the costly flexibility of the agent.

The best systems I have built are neither all workflow nor all agent. They are chains where each link runs in the right regime: deterministic when possible, agentic when necessary.

Everything I do today in agentic, I first did in workflow. n8n chains that produced content, Make scenarios connecting business tools, accounts orchestrated end to end. I learned the rigor of the explicit flow before I had agents capable of judgment.

When agentic arrived for real, I did not throw everything out. I kept the workflow where it remained unbeatable: the wiring, the syncing, the deterministic triggering. And I replaced it where it held me back: understanding, decision, production that demands judgment.

What really changed is my appetite. Agentic made me impatient with a scenario editor where you wire nodes by hand for things a governed agent does better. But this impatience is a trap if it pushes me to agentify what was working perfectly well in deterministic mode.

The workflow is not dead. It has become a building block, no longer the system. Zapier, Make, n8n stay excellent for what they do best: executing the predictable, fast and cheap.

The real work, from now on, is knowing where the boundary lies between the deterministic and the agentic. That boundary is neither a question of tool nor a question of fashion. It is a decision of architecture and cost. And that is exactly the architect's job.