The rule I now use to decide between deterministic and agentic in n8n

Tips & Tricks
, , ,
1

:waving_hand: Hey n8n Community,

Last week I posted about turning a deterministic invoice classifier into an agentic version and concluded the agent didn’t earn its keep. Got a lot of good comments – including one that’s been stuck in my head ever since:

“Deterministic workflows break loud. Agentic workflows break quietly – sometimes the agent continues to ‘work’ even when what it’s doing is actually wrong.”

That comment crystallized something I’d been feeling but couldn’t name. So this post is the other side of the question: when does agentic actually make sense?

:compass: Quick context: what these terms mean

A deterministic workflow follows fixed rules. Same input → same output, every time. Think IF nodes, Switch nodes, hard-coded routing logic. You define the path, the workflow walks it.

An agentic workflow hands the decision-making to an LLM. You give the agent a goal and a set of tools, and it decides which tool to call, in what order, with what arguments. The path isn’t fixed – the agent figures it out per run.

Both can solve the same problems. The question is which one you should reach for.

:memo: The rule I use now

If I can sketch the entire workflow on paper – incoming document formats, expected fields, decision points, branches, edge cases – go deterministic. As long as hard-coded rules can decide things, deterministic is cheaper, faster, and way more reliable.

If I can’t fully sketch it because there are too many open variables – document formats I haven’t seen before, decisions that depend on context the workflow can’t anticipate, edge cases I genuinely can’t enumerate – that’s when agentic earns its keep.

:inbox_tray: Example: invoice classification (deterministic wins)

I know the inputs (PDF, PNG, JPG). I know the categories (medical, restaurant, hotel, trades, telecom). I know the routing logic (one folder per category, one review folder for low confidence). I can sketch the whole thing on a napkin. Hard-coded rules + an extractor with confidence scoring beats an agent every time.

:e_mail: Example: support email triage (agentic wins)

A new support email comes in. To handle it, the workflow needs to:

  • Read the email and figure out if it’s a bug report, a billing question, a feature request, or something weird that doesn’t fit
  • Pull the customer’s recent ticket history
  • Decide whether to draft a reply, escalate to a human, or close as duplicate
  • For draft replies, pull relevant docs from the knowledge base

I can’t sketch this on paper. The decision tree branches based on content I can’t predict, ticket history I can’t pre-classify, and “is this a duplicate” judgments that need actual reading. This is where an agent stops being a liability and starts being the right tool.

:magnifying_glass_tilted_left: The failure-mode difference

This is what the commenter nailed. When my deterministic workflow breaks, an IF node fails, a node throws an error, the execution stops, I get an alert. I find out fast.

When an agent breaks, it often keeps going. It picks the wrong tool, fills the wrong parameter, classifies a contract as an invoice – and the workflow finishes “successfully.” You don’t find out something’s wrong until someone downstream notices the bad output.

For tasks where being wrong silently is worse than failing loudly, agentic is the wrong call.

:file_folder: Both workflows from last week’s post if you want to compare:

:speech_balloon: Not sure which approach fits your use case?

Drop it in the comments – what you’re trying to build, what the inputs look like, what decisions need to happen. Happy to think through it with you and figure out whether deterministic, agentic, or some mix makes the most sense. Always interesting to see where the line sits for different problems.

Best,
Felix

1 Like
2

I think the failure-mode distinction is a part that doesn’t get talked about that much. The silent failures are usually harder to catch than loud ones. A “successfully” completed workflow with the wrong output will take much longer to catch than one with an error.

That napkin test is solid. A lot of workflows seem like they need an agent only but usually have just one or two truly unpredictable decision points. You can usually isolate those and keep the rest of the flow deterministic. This will keep problems small if an agent gets things wrong.

2 Likes
3

Hi @easybits :waving_hand: : thanks for sharing this, it is a very useful comparison.

What I find most interesting here is the distinction between syntax errors and semantic errors in workflow design. A syntax error means the workflow fails structurally; a semantic error means the workflow runs successfully, but the output is still logically wrong.

That is why I think classical software testing concepts are still very relevant in AI workflows:

  • Data-driven testing: executing the same workflow against many input/output pairs to measure consistency.
  • Edge-case testing: validating behavior on unusual, rare, or adversarial inputs.
  • Regression testing: rerunning the same cases after every change to ensure the workflow has not degraded.
  • Behavior validation: checking whether the workflow matches the intended business outcome, not only whether it executes without errors.

For complex AI workflows, I think the best practice is not to rely on execution success alone, but to define a testing plan, a test cycle, and explicit expected outcomes.

It is also great that n8n now has an Evaluation node See :backhand_index_pointing_right: Documentation, because that gives us a native way to evaluate AI workflow reliability against known test cases and metrics. That feels like the right bridge between software engineering discipline and AI workflow development.

So for me, the real lesson is: deterministic vs agentic is not just an architecture question, it is also a testing question.

2 Likes
4

Hey @AnthonyAtXRay , totally agree with you – the point about using agents specifically for handling unpredictable cases makes a lot of sense. There’s no need to turn an entire workflow agentic just because a few decision points could benefit from it.

2 Likes
5

Hey @Haian_Abou-Karam , thank you for the kind words and for sharing your insights – I completely agree with your point.

The decision really has multiple layers, and testing should definitely be one of them to ensure you end up with a robust solution. The Evaluation node also sounds very interesting – I’ll definitely check it out!

1 Like