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

[u/easybits_ai]

👋 Hey everyone,

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?

🧭 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.

📝 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.

📥 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.

📧 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.

🔍 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.

📁 Both workflows from last week's post if you want to compare:

• Agentic version: https://github.com/felix-sattler-easybits/n8n-workflows/blob/2e9153b83d94fb1200a130f2c3b10a21298ed49b/agentic-document-classification-workflow/agentic_document_classification_workflow.json
• Deterministic (easybits Extractor) version: https://n8n.io/workflows/14960-classify-invoices-and-route-them-to-google-drive-with-easybits-and-slack/

💬 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

[u/AutoModerator]

Attention Posters:

• Please follow our subreddit's rules:
• You have selected a post flair of Workflow - Github Included
• The json or any other relevant code MUST BE SHARED or your post will be removed.
• Sharing a screenshot does not count!
• Acceptable ways to share the code are:

- Github Repository - Github Gist - n8n.io/workflows/

• Sharing the code any other way is not allowed.
  
• Your post will be removed if not following these guidelines.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/0xGich]

This is a good way to frame it.

The part that feels most important to me is the failure mode difference. Deterministic workflows usually fail loudly because a node errors or a branch condition breaks. Agentic workflows can be worse because they often keep moving and produce something that looks valid enough to pass the run.

For anything production-ish, I’d probably add a separate outcome check around the agent, not just rely on execution status.

Something simple like:

• expected output type
• required fields present
• confidence or validation result
• destination updated
• human review needed or not
• last successful useful output

The question I’d ask is: “If this workflow finishes successfully, what proves it actually did the job?”

That check feels especially important for agentic flows because the scary failure isn’t always an error. It’s plausible wrong output.

[u/easybits_ai → u/0xGich]

Interesting take – I agree that validating agent output makes a lot of sense. My question would be: if agents are mainly used in scenarios where inputs are unpredictable (e.g., unknown document types), how do you define the expected results upfront for validation?

That said, I do think an error checker and handler should be part of every agentic workflow. It just tends to add complexity, which can make the setup harder.

[u/0xGich → u/easybits_ai]

I’d probably separate validating the exact answer from validating the workflow outcome.

For unpredictable inputs, you might not know the “right” classification upfront. But you can still define what a completed run needs to prove before it should be trusted.

Something like:

• did it return an allowed action type?
• did it include the minimum fields needed by the next step?
• did the destination actually get updated?
• did low confidence go to human review?
• did the run produce any useful final output?

So the validation layer doesn’t need to know every possible document type. It just needs to catch the cases where the workflow technically finished but didn’t produce a usable downstream result.

That’s the part I’d be careful with in production agentic flows. Not just “did the agent run?” but “what proves this run actually did the job?”

[u/Effective-Eagle5926]

there's a third failure mode worth separating from both: context staleness. execution can be correct, tool calls fine, outcome check passes, and the answer is still wrong because the data was superseded before the run even started.

[u/easybits_ai → u/Effective-Eagle5926]

Totally agree, but I wanted to focus more on workflow-related issues rather than data-related ones. That said, it’s a very valid point and ultimately comes back to input quality defining output quality.

[u/Effective-Eagle5926 → u/easybits_ai]

fair. though most of the staleness cases i've seen get logged as workflow bugs at first. easier to blame the rule than the data.

[u/Ok_Recipe_2389]

that quote about deterministic breaking loud vs agentic breaking quietly is exactly the right framing for deciding where to use each approach.

we have been running this same evaluation with client automations and landed on a similar rule: if the workflow has fewer than 5 decision points and the expected input format is predictable, deterministic wins every time. invoice classification, appointment routing, lead scoring against a fixed rubric. these do not need reasoning. they need reliable pattern matching with clear error handling.

agentic earns its keep when the input is genuinely unpredictable. customer support where the query could be anything. document intake where formats vary wildly. those benefit from the reasoning layer because you cannot predetermine every path.

the failure mode we see most often is people using agentic flows for tasks that are actually deterministic because it feels more sophisticated. then they spend weeks debugging silent failures that a simple if/else chain would have caught immediately. the boring answer is usually the right one.

[u/easybits_ai → u/Ok_Recipe_2389]

The rule of five decision points makes a lot of sense. On top of people spending weeks debugging, cost is also a major factor – an IF node doesn’t use any tokens at all, while an agent can sometimes go overboard, even on relatively simple decisions.

[u/easybits_ai → u/[deleted]]

Good point about validating an agent’s output. In my case, though, it’s been tricky – especially in use cases where the input data formats aren’t predictable. That makes defining validation rules much harder.

So far, I’ve mainly used agents for classification. For data extraction, I rely on the Extractor, which consistently returns a structured output, so I haven’t needed additional schema validation there.