Someone made a case on X that deterministic automation — fixed steps, observable, the same path every time — should be the default for anything running in production, and agents that decide their own tool calls should stay out of it. The replies split into the usual camps: agent people said deterministic tools can't handle anything messy, workflow people said agents are a liability nobody can debug. Twenty-two replies in, the thread had drifted into hybrid-architecture hand-waving without anyone naming the actual dividing line.
Here's the line, and it has nothing to do with which technology is newer:
Can you write the steps down before the request arrives?
If yes, you don't need an agent. You need a workflow, and every extra bit of "intelligence" you bolt onto it just adds a failure mode you can't predict. If no — if the input genuinely varies enough that a fixed sequence breaks half the time — that's where an agent's ability to reason about what to do next actually earns its cost.
Why "boring" wins by default
A deterministic n8n workflow does the same five steps every time, in the same order, and logs each one. When step three fails, you know exactly which step failed and why. When you need to explain to a client why an invoice went out twice, you can point at the log. None of that is true of an agent choosing its own path — the failure could be a bad tool call, a misread instruction, or a reasonable-sounding decision that was still wrong, and you often can't tell which without re-running the whole thing in a debugger.
That's the case for keeping anything that touches money, a customer record, or a compliance obligation on rails. My own reply to that thread was blunt about it: deterministic for anything touching money or a customer, agent only where the input is genuinely messy. Boring, but I sleep.
Where the boring version actually breaks
The honest counterpoint is real, though. A deterministic workflow only works because someone enumerated the cases in advance. The moment your intake is a free-text message, a phone transcript, or an inbox full of vendors who all phrase the same request four different ways, a fixed IF-branch tree starts missing cases nobody thought to add. That's not a workflow problem you patch with more branches — it's a sign the front end of the process needs something that can read intent, not match keywords.
We covered the mechanics of that split in an earlier post on lead routing: pattern-matching on keywords or sentiment falls apart on real customer language, but the fix wasn't "replace the whole workflow with an agent." It was letting a model extract structured facts from messy text, then handing those facts to the same kind of deterministic logic that was already reliable.
The failure mode nobody budgets for
There's a second thread worth pulling in here, from a different reply on X the same week: production agents are distributed systems, not prompts. They need state, retries, timeouts, and permissions like any other service talking to other services — and that's where the real cost shows up. My reply to that one was about the specific case that bites hardest: the timeout one is brutal — "did it not send, or did it send twice" is a question you only want to ask yourself once.
That's not an AI problem. It's the same idempotency problem any webhook-driven system has, and we've written about the fix before. But an agent makes it worse, because a timeout mid-reasoning doesn't just retry a request — it can retry a decision, and the agent may not make the same one twice.
The split that actually works
In practice, the systems that hold up in production aren't purely one or the other. The agent's job is to read the messy input and turn it into a small set of structured facts or a decision — classify the lead, extract the invoice amount, decide which department this belongs to. The deterministic workflow's job is to take that decision and execute it the same way every time, with logging, retries, and an idempotency check at every write. The agent decides once; the workflow does the boring part reliably, over and over, without reinventing the sequence each run.
If you're scoping an AI agent or an automation build and you're not sure which side of that line your process sits on, that's usually the first thing worth figuring out before any code gets written. We've built both sides of this split for clients, and the ones that break in production are almost always the ones where an agent was asked to do a workflow's job. If you want a second opinion on where your process falls, get in touch.
— Cole
Sources
- X — @jurlycat on deterministic tools vs. agents in production (thread that prompted this post)
- X — @panditdhamdhere on production agents as distributed systems