6. When to use an agent and when not to

Description

By the end of this lesson you'll be able to take a real automation case and decide, with a concrete criterion (not intuition), whether it needs an agent that reasons and picks tools or whether a deterministic workflow with IF/Switch solves the same thing with less cost, less latency, and less risk. You'll also be able to recognize the signs that a team stuck an agent where one wasn't needed.

This matters because it's the mistake that costs the most money in AI automation projects: building an agent for a case with three fixed routes (something a Switch solves in seconds and with no LLM bill), or the reverse, forcing an endless IF chain for a case where the input is so variable that no decision tree covers it. A client who asks "automate my support replies" isn't asking for an agent — they're asking for the problem to be solved. Sometimes the correct answer is the most boring one.

Connection to the module: in the previous lesson you saw the four pieces that connect to the agent (model, prompt, tools, memory). This lesson is the filter that goes before those pieces: it decides whether connecting them is even worth it.

The cost of autonomy

Imagine you run a store and need someone to cover the register for a day. You have two options for the person covering it:

You hand them a manual with fixed steps: "if the customer pays cash, do X; if they pay by card, do Y; if they ask for an invoice, do Z." The person doesn't think, they execute. It's fast, predictable, and if something goes wrong you know exactly which step failed.

Or you give them the company card and the judgment to use it: "solve the customer's problem, you have a budget of up to $500, and you can ask for help if you're unsure." That person can handle cases the manual never anticipated — a customer with an odd problem, a situation that combines two rules — but they can also make a decision you wouldn't have made, and each decision takes them longer to think through.

A deterministic workflow in n8n (IF, Switch, Code nodes chained together) is the manual: fixed routes, known in advance, no surprises. An agent is the company card: the model decides which tool to use, in what order, and when to stop. That decision isn't free — you pay for it again at every step of the agentic loop. Anthropic sums it up this way in its guide to engineering agents: "the autonomous nature of agents means higher costs, and the potential for compounding errors" (see Resources). Every turn of the reason → act → observe cycle you saw in lesson 3 is another call to the model — and another chance for it to misinterpret the input.

This gives you a quick question to ask before touching the AI Agent node:

Question	If you answer YES	If you answer NO
Can you enumerate all possible routes in advance (2, 5, even 15 cases)?	Deterministic workflow	Keep evaluating
Must the same input always produce the same output (audit, compliance, billing)?	Deterministic workflow	Keep evaluating
Is the volume so high that one extra LLM call per case hits your monthly cost?	Deterministic workflow (or single-step procedural AI, G6)	Keep evaluating
Does the task combine several sources or tools in an order that depends on what the customer says, not on a fixed rule?	Agent	Deterministic workflow

If you answered "deterministic workflow" on two or more rows, that's your path — even if the project sounds more interesting as an agent.

Worked example: same WhatsApp inbox, two different inquiries

A support team receives WhatsApp messages. Two inquiries come in the same day:

Inquiry A: "What are your business hours?"

This has a single, known route: classify the intent (one call to an LLM, procedural AI — what you already saw in G6) and reply with fixed text from a Set node. There are no tools to choose between, no order to decide. If you build an agent for this, the model is going to "reason" only to end up doing exactly what an IF would have done in zero extra calls.

• Input: the WhatsApp message.
• Process: a classification node (LLM Chain, 1 call) detects the hours intent → Switch routes to the fixed branch.
• Output: "We're open Monday to Friday, 9:00 to 18:00 local time." Always the same, always cheap, zero surprises.

Inquiry B: "I need to change the delivery address for order #4521, and while I'm at it I want to know if this week's discount still applies before I confirm."

Here there's no fixed route: the model has to decide in what order to resolve two related things, and the order matters (if the discount no longer applies, the customer might not want to change anything). This is a real agent candidate:

• Input: the same WhatsApp message, but with two chained requests.
• Process (agentic loop, 3 turns):
  1. The agent identifies it needs the order → calls the lookup_order(order_id=4521) tool → observes the result (current address, order status).
  2. The agent identifies it needs the discount rule → calls the check_discount(customer_id, week=current) tool → observes the result (applies or not).
  3. The agent composes the final reply combining both results and decides whether to ask for confirmation before executing the change.
• Output: "This week's discount no longer applies to orders modified after 48 hours — your order was placed 3 days ago. Do you still want me to change the address to the new one you gave me?"

Interpretation: Inquiry A resolved in 1 LLM call and zero tools. Inquiry B needed 3 calls (one per loop turn) plus two real tool executions. If your daily volume is 500 type-A inquiries, building an agent for all of them costs you 3x the cost and latency you need — the Switch's determinism comes free by comparison. If your volume is 50 type-B inquiries a day, the agent is the only reasonable way to cover that combinatorics without writing an IF for every possible combination of order + discount + payment method.

Signs of over-engineering

These are the signs that a team built an agent where a simple workflow would have been enough — check them against any agent you inherit or build:

• The agent only uses one tool, always in the same order. If you review the last two weeks of executions and see it always calls the same tool first, never skips a step, never changes the order, that's not an agent — it's a deterministic workflow in disguise, paying the cost of having the model "decide" something that was already decided.
• The system prompt is actually an algorithm. If your prompt says "first do X, then if Y happens do Z, otherwise do W," you're trying to force determinism inside a component designed to exercise judgment. That algorithm should live in IF/Switch nodes, not in text the model can misread.
• Nobody can explain why the agent took a certain route in production. If a case went wrong and the team shrugs ("the model decided that way"), that's acceptable for a content recommendation, but it's a red flag if the case involved money, sensitive data, or an irreversible action.
• The monthly LLM cost goes up and response quality doesn't improve. If you're paying for more calls (more loop turns, more context tokens from memory) without the end user noticing any difference, you're paying for autonomy nobody's using.

Common mistakes

1. Believing "agent" means "better." This is the most common conceptual misunderstanding: treating autonomy as a feature that comes for free, as if an agent were "a chatbot with more power." It isn't — it's a different component, with a per-decision cost and a different failure mode (unpredictable routes) than a workflow's (fixed routes you can test one by one). How to spot it: if you list the cases your "agent" handles and count 2 or 3 routes that are always the same, you already have your answer. How to fix it: replace the AI Agent node with a classification node (procedural AI, a single call) + Switch with the fixed routes.

2. Confusing "the input is natural language" with "I need an agent." Just because the message arrives as free text doesn't mean the resolution has to be autonomous — you can classify the intent with a single prompt and then run a fixed branch, which is exactly G6's procedural AI pattern. How to spot it: check whether your agent, in practice, never combines more than one tool or changes the order between executions. How to fix it: separate "understand what the user wants" (classification, 1 call) from "execute the action" (deterministic nodes); reserve the agent for when the order of the actions also depends on context.

3. Giving irreversible tools to a production agent with no approval step. What happens: the agent decides when to use a tool, not just how — if you give it access to "cancel order" or "send refund" with no oversight, a misreading of the input translates directly into a real action, not into text you can correct later. Why it happens: it's easy to think of tools as "functions the agent can call" and forget that every tool with an effect on the real world needs its own risk analysis. How to spot it: classify your tools as reversible (search, read, list) and irreversible (cancel, send, delete, charge). How to fix it: for the irreversible ones, add a human approval step before execution — n8n has native support for this (see Resources). This topic gets a full treatment in the agent security and reliability module later in the guide.

Exercises

Exercise 1. An e-commerce business wants to automate: "when an email arrives at support@, if the subject contains the word 'return', create a ticket in the ticketing system with high priority." Agent or deterministic workflow? Justify your answer with at least two rows from the decision table.

See solution

Deterministic workflow. The route is fully enumerated in advance ("if it contains word X, do Y") and doesn't depend on the model choosing between several tools or deciding an order — it's an IF (or even a text filter) followed by ticket creation. Also, the same input (subject with "return") must always produce the same output (high-priority ticket): that's the second row of the table, and by itself it already rules out the agent. Putting an AI Agent node here only adds an LLM call (cost and latency) to make a decision an IF makes in zero calls.

Why this answer works: it applies the route-enumerability criterion before looking at anything else — if the routes can be counted and are fixed, the agent adds nothing that determinism doesn't provide more cheaply.

Exercise 2. A sales team wants a WhatsApp bot that: receives a lead's question, searches the product catalog for a match, checks available inventory, and if there's stock, offers to schedule a call — but if the lead asks about a discontinued product, it should suggest an alternative before offering the call. Agent or deterministic workflow?

See solution

Agent. The table's fourth row applies: the task combines several sources (catalog, inventory) in an order that depends on what each one returns, not on a fixed rule — if the product is discontinued, the next step changes (suggest an alternative before offering the call). Enumerating every possible combination with IF/Switch (product exists × there's stock × it's discontinued × there's an alternative) grows fast, and any new product in the catalog breaks the decision tree. An agent with search_catalog and check_inventory tools can compose the correct sequence case by case without you rewriting the logic every time the catalog changes.

Why this answer works: the deciding criterion isn't "there's natural language" (both exercises have that), but whether the order of the actions varies depending on what each source returns — that's where determinism stops scaling.

Exercise 3. You have an agent in production with a single tool, send_email, and you review the logs from the last 200 executions: in 100% of the cases the tool is called exactly once, after the same classification question. Which sign of over-engineering applies, and what would you do?

See solution

The first sign applies: "the agent only uses one tool, always in the same order" — that's a deterministic workflow disguised as an agent, paying on every execution for a decision that's already decided (it's always the same tool, always after the same step). The fix is to replace the AI Agent node with: a classification node (1 call, if you truly need an LLM to draft the email) followed by a fixed Send Email node — or even removing the LLM entirely if the email content is also fixed.

Why this answer works: the evidence (200 structurally identical executions) is exactly the kind of data you should check before trusting the intuition that "this needs to be an agent."

Summary and next step

You now have the filter that decides whether it's worth connecting the four pieces you saw in the previous lesson: route enumerability, need for determinism, volume and cost, and whether the order of the actions depends on context. This is the criterion you'll apply every time someone asks you to "automate this with AI" — before opening the AI Agent node, before thinking about tools or memory.

Before moving on you should be able to: take an automation case described in one sentence and classify it as agent or deterministic workflow, justifying with at least one row from the decision table — and name at least two signs that an existing agent is over-engineered.

With that decision made, what's left is where you're going to run the agent once you decide to build it — that's the territory of the next lesson.

Resources

• Building Effective Agents — Anthropic's guide that originates the "workflow vs. agent" framework and the quote about the cost of autonomy cited in this lesson; explains when an agent's complexity is justified and when it isn't.
• Agents vs chains — n8n's official documentation comparing the AI Agent node against a simple chain, with a sample workflow.
• What agents do — how n8n describes the agent's decision cycle (setup, tool calls, evaluation, response).
• How tools work — what tools n8n ships out of the box and how they connect to the agent; useful for sizing how many calls each tool adds.
• Human-in-the-loop for tools — how to insert a human approval step before the agent executes an irreversible tool, the subject of this lesson's third common mistake.