2. Agent, chatbot, and procedural AI: three different things

Description

In the previous lesson you saw where this guide is headed: you'll end up building an agent that responds across several channels. Before touching the node that makes it possible, you need a criterion for classifying any AI flow you come across — yours or a client's — into one of three categories: procedural AI, single-turn chatbot, or agent (also called agentic AI). By the end of this lesson you'll be able to look at an n8n flow with an AI node inside it and say, in one sentence, who controls the next step: the flow you already designed, or the model at runtime.

This isn't an academic exercise. In real automation projects, "I need an AI agent" is one of the most misused phrases in the market: half the time the client actually needs a chatbot that answers an FAQ — much cheaper and more predictable — and other times they need exactly the opposite of what they're asking for: a flow with fixed rules, because their process can't afford to improvise. Knowing how to name the difference precisely is what lets you scope a project correctly instead of over-building or under-building the solution.

Connection to the module: this classification criterion is the foundation the rest of the module rests on. The next lesson opens the AI Agent node and looks at what happens inside it when it decides to call a tool; this lesson answers the why behind that decision existing in the first place.

The criterion: who decides, not how conversational it sounds

Picture a customer service counter with three different setups for the same question: "how's my order #3187 doing?"

At the first counter there's an employee with a printed instruction sheet: if the customer says the word "order," send them to logistics; if they say "invoice," send them to billing; anything else falls into a generic inbox. The employee doesn't decide anything — the instruction sheet already decided everything before the customer arrived. It doesn't matter whether they serve 3 customers or 3,000 that day: the route was already fixed in advance.

At the second counter there's someone who knows the catalog and company policies very well, and answers confidently and with good tone — but doesn't have access to the order system. If you ask about your order #3187, they'll give you something reasonable ("shipments usually take 3 to 5 days"), but they don't know where your package is right now. They converse, but they don't act on anything.

At the third counter there's someone with the keys to the system: they listen to the question, decide for themselves whether they need to check the order system, check it if needed, and answer with the real data. If instead you ask about the return policy, they answer directly, without touching any system, because they decided they didn't need it for that question. Nobody programmed a case for every possible question: the person decides on the spot, with every new question.

Those three setups have technical names:

• Procedural AI: the flow decides. A Switch (or IF) node evaluates fixed conditions you set at design time and routes the message down a predetermined path. There can be an AI node inside one of those branches — for example, to classify a message's sentiment — but who chooses the overall route is still the Switch, not the model.
• Single-turn chatbot: the model decides what to say, not what to do. It receives a message, generates a natural-language reply, and stops there. In n8n this is typically built with the Basic LLM Chain node: according to n8n's official documentation, a chain of this type has no access to memory and doesn't decide between tools — it only chains a single call to the model.
• Agent (agentic AI): the model decides what to do before deciding what to say. It receives a goal and a set of tools, and at runtime it chooses whether it needs to call one, with what arguments, and when it already has enough to answer. n8n's documentation sums it up with an idea worth memorizing: an agent is, in essence, a chain that already knows how to make decisions.

That's exactly the boundary with procedural AI: on that ground, the flow decides even when a model is involved. Here, in agentic AI, it's the model that decides the path.

Worked example

Take the same counter question — "how's my order #3187 doing?" — and build it three times in n8n, with the same entry point (a Chat Trigger node, n8n's standard entry point for chatbots and agents) but different backends.

1. Procedural AI

Chat Trigger
  → Switch (does the message contain "order" / "shipment" / "status"?)
      branch YES → Edit Fields (extract the order number with a regular expression)
                → HTTP Request (GET to the shipping API with that number)
                → Edit Fields (build the reply text)
      branch NO → fixed generic reply

What to expect: if the customer writes "where's my package?" instead of using the word "order," the message doesn't match any Switch rule and falls into the generic branch — even though the intent is identical. The flow is fast, cheap, and 100% predictable, but it only covers the phrases you anticipated when designing it.

2. Single-turn chatbot

Chat Trigger
  → Basic LLM Chain (system prompt: "You are the support assistant for Fast Shipping Co.")

What to expect: the model answers with good tone and knows the company's general policies — because you gave them to it in the prompt — but it has no way to check the real order. An honest reply would be "I don't have access to that information right now"; the real risk is that, with no tool holding it back, it invents a plausible shipping status, because nothing in its construction stops it.

3. Agent

Chat Trigger
  → AI Agent (connected to a chat model + an HTTP Request Tool
              pointing at the shipping API)

At runtime, the model interprets the message and decides to call the tool:

// What the model generates to invoke the tool
{ "tool": "check_shipment_status", "arguments": { "order_number": 3187 } }

// What the tool returns
{ "status": "in_transit", "eta": "2026-07-25" }

And it composes the final reply from that real data: "Your order #3187 is in transit, arriving July 25."

Now, if you ask that same agent — without changing a single node — "what's the return policy?", the model decides not to call the tool (it doesn't need it for that question) and answers directly from its knowledge. Same node, two different behaviors depending on what each message asks for. That's what you can't achieve with a Switch: you'd have to anticipate every possible phrase with a new branch. That internal back-and-forth — deciding, acting if needed, deciding again — is exactly the cycle you're going to dissect in the next lesson; for now, hold onto the effect it produces from the outside: different decision, same node.

A quick intuition for when to use each one

• Procedural AI when the decision space is small, known in advance, and needs to be deterministic and auditable — billing, regulatory compliance, anything where "why did it take that route" has to have an exact answer.
• Single-turn chatbot when you only need a natural-language interface over static knowledge — FAQ, onboarding, policies that don't change — and you don't need to touch any external system.
• Agent when the range of user requests is open-ended and the action needed depends on what's asked each time, something you can't enumerate with Switch branches in advance.

This is a starting intuition, not the complete criterion: later in the module you'll build a more rigorous way to decide this, costs and warning signs included.

Common mistakes

1. Thinking "having an AI node in the flow" already makes it an agent (conceptual). What happens: someone builds a Switch that in one of its branches uses a Basic LLM Chain to classify the message, and calls it an "agent" in the project documentation. Why it happens: it confuses the presence of a model with a model that decides the path. How to spot it: ask yourself who chose the route — if it was a fixed condition you wrote, it's procedural AI with an AI ingredient inside, not an agent, no matter how sophisticated the prompt sounds. How to fix it: if the real requirement is that the system choose the action based on what each message asks for, replace the Switch + chain with an AI Agent with tools; if the decision space is still small and fixed, fix the name in the documentation, not the flow.

2. Simulating an agent by hand with nested Switches covering every possible phrase. What happens: the flow ends up with fifteen or twenty branches trying to capture variations of "where's my order?", "I want to know about my shipment," "nothing arrived"... and every new phrase from the customer that doesn't match any of them breaks the flow. Why it happens: an attempt is made to solve — with fixed branches — a problem that the model exists precisely for: generalizing over variable natural language. How to spot it: if your Switch has more than five or six branches trying to capture the user's intent (not a structured piece of data), that's the signal. How to fix it: move that intent decision to the AI Agent — you'll build it in lesson 4 — and leave the Switch only for what actually is deterministic, like routing by input channel.

3. Dismissing the single-turn chatbot as "useless for anything real" (conceptual). What happens: everything gets agent-ified by default, even a static FAQ that never needs to touch an external system, and the result is a flow that's more expensive in tokens, slower, and less predictable, with no real gain. Why it happens: it's hard to see that an agent isn't "the upgraded version" of a chatbot, but a different architecture with a different cost, one that's only justified when the task truly requires deciding between actions. How to spot it: check whether your use case ever needs to vary the action based on what the user asks, or touch an external system; if the answer is "never," a single-turn chatbot — or even procedural AI — solves it with less risk. How to fix it: apply the "who decides" criterion before choosing the architecture, not after building it.

Exercises

Exercise 1. A flow receives a support message. A Switch node checks whether the text contains the word "urgent"; if so, it sends a Slack notification; if not, it does nothing else. There's no model involved. Is it procedural AI, a single-turn chatbot, or an agent? Justify your answer with the "who decides" criterion.

See solution

It's procedural AI. The Switch evaluates a fixed condition (contains or doesn't contain the word "urgent") written at design time, and the route is determined before any real message arrives. No model is making that decision — there isn't even a model in the flow. It works because the decision doesn't depend on interpreting variable natural language: it's a fixed text search.

Exercise 2. You have an AI Agent connected to three tools: look up order, issue refund, and escalate to a human. A customer writes: "I want to cancel my order #789 and get my money back." What determines which tool (or tools) get called and in what order?

See solution

The model determines it, at runtime, by interpreting the request — not a Switch or a list of rules you wrote. It's reasonable for the model to first call "look up order" (to verify order #789 exists and is cancellable) and then call "issue refund," but that sequence was never hardcoded with logic nodes. Even though the three available actions are perfectly well defined — this isn't magic, they're concrete functions — what makes this an agent and not procedural AI is that nobody fixed in advance the order, or which of the three are needed for this particular message.

Exercise 3. An internal tool only needs to answer "what is the company's vacation policy?" using the fixed text of the HR handbook. It never needs to query an external system or vary the action based on what the employee asks. Would you build it as a single-turn chatbot or as an agent? Justify your answer.

See solution

As a single-turn chatbot (Basic LLM Chain with the handbook text in the prompt or added as context). There's no external system to query and no action to vary based on the question — the space of "things to do" is zero, there's only text to interpret and paraphrase. Building it as an agent would add the token cost and unpredictability of deciding between tools, with nothing gained in return: there's no tool that's actually needed.

Summary and next step

The criterion you're taking from this lesson is simple to state and hard to misapply if you remember it well: the question is never "is there an AI model in the flow?", but "who decides the next step: the flow you designed, or the model at runtime?" Procedural AI: the flow decides. Single-turn chatbot: the model decides what to say, not what to do. Agent (agentic AI): the model decides what to do.

What you saw here is the what that distinguishes an agent from the outside. What you haven't seen yet is the how: what exactly happens inside the AI Agent node when it decides to call a tool, reads the result, and decides again. That cycle of reasoning, acting, and observing is the subject of the next lesson, and it's the underlying reason that behavior can't be replicated by hand with logic nodes, no matter how many Switch branches you add to it.

Before moving on you should be able to take any n8n flow with an AI node inside it and say, in one sentence, whether the model controls the path or the path was already fixed in advance — and explain why, using the #3187 order example if needed.

Resources

• Agents vs. chains — n8n's official distinction between the two, with the role of tools and memory.
• What do AI agents do? — the source of the definition "an agent is a chain that knows how to make decisions."
• How tools work — what a tool is and how an agent decides when to use one.
• AI Agent node — reference — official documentation for the node you'll build in lesson 4.
• Basic LLM Chain node — reference — the node behind this lesson's single-turn chatbot.
• Chat Trigger node — reference — the entry point shared by all three examples.