Basic LLM Chain vs AI Agent in n8n: Which One Should Your Workflow Use?
Published 1 August 2026 · 6 min read
In n8n's AI section, two nodes appear to do the same thing: the Basic LLM Chain and the AI Agent both take a prompt, call a language model, and return a response. Picking the wrong one has very tangible consequences, though: an agent used where a chain would have sufficed multiplies LLM calls, latency, and your bill, while introducing non-determinism exactly where you did not want any. This guide lays out the decision criteria, with a comparison table, workflow examples for each case, and the specialized in-between nodes that often replace the agent entirely. If you are just discovering n8n's AI toolkit, start with our introduction to n8n's AI nodes before diving into this comparison.
Two nodes, two philosophies
Both nodes are built on LangChain, but their internal mechanics have nothing in common.
The Basic LLM Chain makes exactly one call to the model: your prompt goes in, the response comes out, the node hands over to the next one. No tools, no memory, no loop. Its only side connections are the model (required) and, optionally, an output parser to enforce an output format. One call means a known cost, roughly constant latency, and behavior that is reproducible from one execution to the next.
The AI Agent runs a reasoning loop: the model reads the task, decides whether it needs a tool (HTTP request, vector search, calculation, sub-workflow...), receives the tool's result, reasons again, and repeats until it considers the task done — within the limit of the Max Iterations parameter. It accepts tools, conversation memory, and an output parser. This design follows the ReAct paradigm formalized by Shunyu Yao and co-authors in "ReAct: Synergizing Reasoning and Acting in Language Models", published at ICLR 2023: interleaving reasoning steps with actions on the environment markedly improves tasks that require fetching information, compared to a model answering in a single shot.
The practical consequence: one agent execution may represent one, three, or ten LLM calls depending on what the model decides. Cost and latency become variables, not constants. Our complete guide to the AI Agent node walks through this mechanic connection by connection.
Comparison table
| Criterion | Basic LLM Chain | AI Agent |
|---|---|---|
| LLM calls per execution | Exactly 1 | 1 to N (loop, capped by Max Iterations) |
| Tools (HTTP, vector store, code...) | No | Yes, dedicated Tools input |
| Conversation memory | No | Yes, optional |
| Cost per execution | Fixed and predictable | Variable, depends on iteration count |
| Latency | One call's worth | Accumulated across all iterations |
| Reproducibility | High (same prompt, same structure) | Lower (the execution path varies) |
| Debugging | Simple: one prompt, one response | Harder: inspect every iteration |
| Typical use case | Transform text known in advance | Decide what to do and with which tools |
When the Basic LLM Chain is enough
The rule of thumb: if you can describe the task as "take this text, produce this output", the chain is enough. A few representative workflows:
- Classifying incoming messages: an email arrives, the chain assigns it a category from a closed list, and a Switch node routes it. One call, a short response, minimal cost.
- Field extraction: pulling name, amount, and due date out of an invoice text or a free-form form submission, as JSON output.
- Rewriting and summarizing: condensing a ticket into two sentences for a Slack notification, translating a product description, rephrasing a draft.
- Template-based generation: drafting a standard reply from variables already present in the item.
A concrete configuration example — a classification chain whose prompt injects the current item's data:
You are a customer request classifier.
Allowed categories: billing, technical, sales, other.
Message to classify:
Subject: {{ $json.subject }}
Body: {{ $json.body }}
Reply with JSON only: {"category": "...", "urgency": "high|normal|low"}
To guarantee that the output is JSON the downstream nodes can actually use (rather than a sentence of explanation wrapped around it), enable the output format option and attach a parser — our guide to the Structured Output Parser shows how to define the schema and handle invalid outputs.
The decisive point: in all these cases, the sequence is known in advance. The model has no orchestration decision to make; your n8n workflow does the orchestrating, with deterministic IF, Switch, and Merge nodes.
When the AI Agent is justified
The agent becomes relevant when the task requires decisions made at runtime:
- The path depends on the content: a support assistant that, depending on the question, must search the documentation (vector store), look up an order status (API), or escalate to a human. You cannot wire all the branches in advance.
- Back-and-forth with tools: check availability, then book, then confirm — each step depending on the previous result. Building bespoke tools is covered in our guide to custom tools for the AI Agent.
- An ongoing conversation: a chatbot that must remember previous exchanges relies on the agent's memory input, detailed in our article on conversation memory for an AI agent.
A sample workflow: a webhook receives a customer question, the AI Agent has three tools (documentation search, CRM lookup, ticket creation), and decides on its own which ones to invoke and in what order depending on the question. That is exactly the scenario a chain cannot cover.
Specialized nodes: the middle ground people forget
Between the raw chain and the full agent, n8n ships specialized LangChain nodes that wrap one precise use case in a single LLM call with an already-structured output:
- Text Classifier: categorization with native output branches per category — more direct than a chain followed by a Switch. See our Text Classifier node guide.
- Information Extractor: schema-based field extraction with built-in validation — the natural replacement for an agent cobbled together to read documents. See our Information Extractor node guide.
- Question & Answer Chain: answering a question against a retriever (vector store) without an agent loop — enough for simple RAG where the only "action" is the documentation lookup.
Many workflows running an AI Agent in production actually use a single tool, always the same one: a Question & Answer Chain or a specialized node would do the same job with fewer calls and less variance.
The classic pitfalls
- An agent for a single-call task: the most common mistake. The agent adds a reasoning turn (or several) around a task the chain settles in one call — you pay for the loop without getting any value from it. Track your per-workflow spend with our method for tracking AI call costs in n8n: the overhead becomes obvious.
- Underestimating non-determinism: the τ-bench benchmark by Yao, Shinn, and Narasimhan (2024), which evaluates tool-using LLM agents on realistic scenarios (airline booking, retail), introduces the pass^k metric to measure consistency across repeated attempts at the same task: reliability drops sharply once you require the agent to succeed on every try rather than once out of several. In production, this means an agent that "works in testing" can fail intermittently on the very same input.
- No safeguards on the loop: cap Max Iterations, plan for the case where the agent does not converge, and go through our review of common AI Agent node errors before shipping.
- Debugging the agent like a chain: a chain is tested by comparing prompt and response; an agent requires inspecting every iteration and every tool call in the execution log — budget that time into your estimates.
Key takeaways
Always start with the question: "is the sequence of steps known before execution?" If yes, a Basic LLM Chain — or better, a specialized node like Text Classifier or Information Extractor — does the job with a fixed cost, single-call latency, and reproducible behavior. Reserve the AI Agent for cases where the model genuinely has to decide what to do: tool selection at runtime, result-dependent back-and-forth, conversation with memory. And if you are still hesitating, the budget criterion settles it quickly: a chain costs one call, an agent costs a number of calls you only find out after the fact.
FAQ
Frequently asked questions
Can you connect tools to a Basic LLM Chain in n8n?
No. The Basic LLM Chain only accepts a model and, optionally, an output parser. It makes exactly one LLM call: prompt in, response out. If your use case requires the model to call an API, search a database, or trigger an action, you need the AI Agent node, which exposes a dedicated Tools input.
Does the AI Agent produce better answers than the Basic LLM Chain?
Not by itself: both nodes call the same model with the same capabilities. The agent is only "better" when the task genuinely requires multiple steps or information fetched through tools. For a single-call task (summarizing, classifying, rewriting), the chain delivers the same quality, faster and cheaper.
How do you limit the number of iterations of an AI Agent in n8n?
In the AI Agent node options, the Max Iterations parameter caps the number of reasoning-tool loops (10 by default). It is an essential safeguard: without it, an agent going in circles can multiply LLM calls, and therefore cost and latency, before failing anyway.
Can several chained Basic LLM Chains replace an AI Agent?
Often, yes. If the sequence of steps is known in advance (extract, then classify, then draft), several chains connected through regular n8n nodes give you a deterministic pipeline that is testable step by step and has a predictable cost. The agent is only justified when the order of steps or the choice of tools must be decided at runtime.
Bundle FlowKit Complet
€269