n8n's AI Agent node: when it pays off and when a plain workflow is enough

n8n’s AI Agent node is tempting because it promises that instead of drawing every branch of a process you can give the model tools and a goal. Using the triage of customer tickets as the example, I show two designs of the same process: once as a plain workflow with fixed steps and once with the AI Agent node and three tools. A caveat up front: these are designs, not results — this article does not publish measurements from a comparison; it shows how to run one. My conclusion from the construction of the two options alone: for basic triage the plain workflow usually wins, because it has a fixed, known sequence of primary model calls, is easier to check and behaves predictably. The agent may start to pay off where what you need to look for next depends on what the previous search returned. What settles it is a test on 50 real tickets, described below — and its results cannot be carried over from someone else’s company to yours.

The general principles for choosing between an agent and simpler automation are on our page about AI agent implementation, and the difference between an agent and a chatbot is in our article AI agent vs chatbot. The n8n basics — what a workflow, a node and an execution are, what n8n Cloud costs and how to handle errors — are in our n8n guide. Here we deal only with the decision: an agent or fixed steps.

What n8n’s AI Agent node lets you do

A workflow in n8n is usually a sequence of steps set in advance: read, check, pass on. The AI Agent node adds a place in it where a language model chooses the next step. The model receives the ticket, a standing instruction (in n8n: the System Message) and a list of tools, and then decides in a loop which tool to reach for, reads the result and decides again — until it judges that it has the answer or it reaches the limit.

According to the n8n documentation (as at 12 October 2026, latest stable release 2.42.7):

• you must connect a model and at least one tool; since release 1.82.0 every AI Agent node works as a Tools Agent, an agent that uses tools;
• Max Iterations limits how many times the model may run for one task — 10 by default;
• Return Intermediate Steps adds the steps the agent took along the way to the output — the basis of an action log;
• Require Specific Output Format requires the output in a set format rather than free text; once it is on, you have to connect a parser, a component that checks and structures the output;
• a tool can be, among other things, a call to another workflow (Call n8n Workflow Tool), a request to an outside system or the tools of an MCP server — MCP (Model Context Protocol) is a standard way of connecting an AI assistant to the tools of an outside system, which we come back to below;
• conversation memory can be connected to the node, but simple memory does not persist between sessions — for ticket triage we do not need it anyway, because each ticket is a separate case.

Option A: a plain workflow with fixed steps

In option A the model works in strictly defined places, and the order of the steps is decided by the design, not by the model:

1. A trigger starts the workflow for every new ticket — from e-mail or from the ticketing system.
2. Information Extractor (an AI node) pulls set fields out of the text: the order number, the customer’s e-mail address, what the case is about. We describe the list of fields ourselves, so a correct output always has the same layout; tickets with missing or doubtful fields go to manual review.
3. Text Classifier (an AI node) assigns a category from our list. Each category has a name and a description the model uses. One important setting: when the model finds no matching category, the node drops the ticket from the rest of the run by default. Change that to a separate “Other” branch that sends the case for manual review — otherwise some tickets quietly disappear.
4. Category branches: Text Classifier has a separate output for each category (and for “Other”), and we wire each one permanently to the right path inside the workflow: an order question triggers a read from the order system (with the same confirmed-identity rule as in option B), a complaint is meant for the complaints team, the rest for the queue. Nothing is written yet at this stage — assigning the ticket to a team or queue is itself a write, so it waits for step 6.
5. A draft reply is prepared by the model in a single call, from the ticket, the data from the previous steps and knowledge-base passages retrieved for that category — the same knowledge base option B uses.
6. Human approval (Send and Wait) comes before any write to the CRM (the system holding customer data), any assignment of the ticket to a team or queue, or any reply being sent, and only then the write.

How the approval step and error handling work is shown with the invoice example in our n8n guide — the flow here is the same. Why ticket triage is a good first process to automate is explained in our article on AI automation examples.

The defining feature of option A: the number of primary model calls per ticket is set in advance — three on the path described (extraction, classification, draft). Retries after an error and automatic output-format repairs can add more, so count them all when measuring. When something goes wrong, you can see in which node.

Option B: the AI Agent node with three tools

In option B one AI Agent node handles the same process. It receives the ticket, a standing instruction describing the triage rules, and three tools:

1. Look up the customer and their orders — a sub-workflow called through Call n8n Workflow Tool that reads from the CRM and the order system, read-only. That sub-workflow enforces its own limits, independently of the model: it identifies the customer from an identity the ticketing system has confirmed (for example a signed-in customer account), not from what the model supplies — a sender’s e-mail address is easy to forge, so without a confirmed identity no order data reaches the agent until a person has confirmed it. If the ticket gives an order number, it checks that the number belongs to that customer before returning anything; if not, it returns that customer’s open orders. Either way it returns only the fields needed. On a mismatch it returns no order details and the case goes to manual review — otherwise a ticket that carries someone else’s order number or a hidden instruction for the model could pull out another customer’s data.
2. Search the knowledge base — procedures, terms and conditions, answers to common questions.
3. Save the result — the category, the data found, the decision on whether the case goes to a person, and the draft reply; it is the only tool that writes anything, and therefore covered by human approval. That way both options leave the same fields to assess, and the approval also covers the category — only after that approval is the ticket assigned, according to that category, to the same destinations as in option A.

n8n lets you require a person’s approval before a selected agent tool is used. The workflow pauses, the approver sees what the agent wants to do and with what data, approval runs the tool, denial cancels it and the model is told it was denied. The approval request can be sent through, among others, n8n’s built-in chat, Slack, Microsoft Teams or e-mail (Gmail or Outlook). This step comes before the write, not after it — a write that someone looks at after the fact is not approval, it is a report. What the approver has to see, and how to keep it from turning into reflex clicking, is covered in our article on human oversight (human in the loop).

The number of model calls in option B is variable: each run of the agent loop is a separate call, and the agent decides itself how many it needs — up to the limit you set.

Comparing the two options

The n8n bill comes out similar in both options: on n8n Cloud one execution is one run of the whole workflow, however many steps it has, and sub-workflow executions — including the ones the agent uses as tools — do not use up the plan’s execution limit. If, however, the design splits the handling of one ticket across several separate workflows started independently, each of them counts separately, so one ticket does not always mean one execution. The difference between the options lies elsewhere: in the model provider’s bill and in the time of the people who track down the causes of errors.

What one ticket costs: a formula instead of a guess

We do not publish a table of costs per ticket here, because we did not run that measurement for this article — and an estimate carried over from someone else’s process misleads. An honest figure comes only from a measurement on your tickets, your model and your tool descriptions. Instead, here is the formula that lets you work out the model-usage cost after the test. A token is the piece of text the model provider charges by:

model-usage cost per ticket (simple case) = the sum over all model calls of (input tokens × input price per million tokens + output tokens × output price per million tokens) ÷ 1,000,000 × exchange rate

Providers usually quote prices per million tokens, hence the division. Take the numbers from the usage data the provider returns, not from assumptions. Before the test, decide how you will record that data for every call — for example from the model provider’s usage dashboard or log, or through a call-tracing tool — because the AI Agent node’s output need not include it; do not count missing data as zero cost. Record the provider’s prices with the date you read them, and the exchange rate with its date and source. If the provider charges different rates for different kinds of tokens (for example, separately for input read from a cache), multiply each category in the provider’s usage report by its own price. Check, too, whether the report gives a total and its breakdown: if cached tokens are already included in the input tokens, apply the ordinary input rate only to the remaining input tokens and charge the cached tokens at their own rate. The n8n subscription, charges for other services and people’s time are separate items.

Why may option B cost more per ticket? In option A there are a few calls, and each receives only what it needs. In option B every call in the loop receives the standing instruction, the descriptions of all the tools and what the agent has gathered so far, so over several runs the agent may use more tokens. Whether, and by how much, has to be measured. The full list of items on the bill for an agent (integrations, oversight, upkeep) is in our article on what an AI agent costs.

When the agent may earn its keep

The agent stands a chance of an edge where what you need to look for next, and where, depends on what the previous search returned. An illustrative run, invented for this article, for a “my parcel never arrived” ticket:

• the customer gave an order number — checking its status is enough;
• there is no number, and the customer, whose identity the ticketing system has confirmed, has two open orders — you have to work out from the message which one the case is about, and only then check its status;
• the status shows a return in progress rather than a shipment — the next step is the returns procedure in the knowledge base, not a reply about delivery;
• the message is not about an order at all — you have to search the knowledge base, and with a different query from the one that would suit the order system.

Each of these paths can be written into option A as another branch. With several systems and many possible search orders, though, the tree of conditions can grow faster than the process, and maintaining it can cost more than the difference in tokens. At that point an agent that picks the next search itself becomes a candidate. Whether it actually picks well is settled by the test.

A third answer: fixed steps with an agent in one branch

In practice the choice is rarely either-or. The option we start from at ploch.ai is a combination: Information Extractor pulls out the fields, Text Classifier assigns a category from a fixed list, and each category has its own permanently wired branch. The model also drafts the reply, and we add the AI Agent node in one branch — the one where you really have to search several systems. Writes to your systems and sending a reply always wait for human approval. In the first version there are no exceptions to that; which actions may later run without approval is decided only by the numbers from the approval period.

The 50-ticket test: how to make the decision

The “agent or fixed steps” decision is made on real tickets, not on a demo. The recipe:

1. Pick 50 real tickets from recent weeks. Deliberately include hard cases: no order number, two topics in one message, another language, an attachment instead of text (turn attachments into text with one shared step in front of both options, so you are not measuring a difference in reading files). Replace personal data with invented data, but consistently — the same invented customer identifier, assigned by the ticketing system, in the ticket and in the test customer record — otherwise the search has nothing to find; tickets without a confirmed identity have manual review as their expected outcome. Before you pick the fifty, refine both options — the instructions to the model, the category descriptions, the fields and the tools — on a separate set of tickets, and freeze them; otherwise the test measures which option was fitted more closely to known cases. Replacing data with invented values limits it but is not anonymisation, so before any ticket text goes into n8n and to the model provider, agree where it is processed, who can access it and when it will be deleted. More on this in our article on the GDPR (General Data Protection Regulation) and implementing language models.
2. For each ticket, write down the expected outcome in advance: the category, the data that has to be found, whether the case should go to a person, and which tools are required, permitted and forbidden. For tickets with two topics, set the rule in advance — for example the category of the more important topic plus a note for a person, or straight to manual review — and write down every expected destination.
3. Run the same tickets through both options on the same, unchanged test data, with writes going to a test destination rather than the real CRM. Both options end at the same point: an approved draft reply saved to the same test destination; sending it to the customer is outside the comparison. Fix the model and its settings for the duration of the test, run each ticket through each option several times and record the spread of results — the model does not answer the same way every time, so a single run can decide the outcome by chance. Show the drafts from both options to the reviewer in random order and without saying which option produced them, to reduce the influence of review order and ticket familiarity on the comparison of checking time. Start the workflow manually from the editor — according to the n8n documentation, manual runs do not count towards the execution limit.
4. For each ticket, record: whether the outcome matches the expected one, the number of loop runs (in option B) and, separately, every actual model call, including retries and output-format repairs, input and output tokens, the factual correctness of the draft reply, the time a person needs to check and correct it, calls to the wrong tool, tickets that hit the Max Iterations limit, and the time it took to find the cause of each error.
5. Set the threshold before the test, not after it. For example: the agent goes in only if it correctly handles the cases the fixed steps cannot cope with, does not break the ones that worked, and its cost per ticket fits the budget. Measure the cost separately, by running a sample that reflects ordinary traffic through both options in the same way, not this deliberately hard fifty.

Fifty tickets is a deliberately selected test set, not evidence of accuracy across all incoming tickets. It is as many as you can review by hand, case by case, and see why the agent got it wrong. Measuring classification accuracy on a larger number of tickets before switching on automatic routing is a separate topic.

MCP tools in n8n

In n8n, the MCP Client Tool node connects tools through MCP: it gives the agent the tools a system’s MCP server offers. The most important setting is Tools to Include: “All” gives the agent every tool on the server, “Selected” only the chosen ones, and “All Except” everything apart from those excluded. Choose “Selected” — the agent should see only the tools needed in this process, not everything the system can do. What connecting an AI assistant to your system through MCP involves is described on our page about connecting an AI assistant to your system.

What to ask of whoever builds it

If you commission an agent in n8n, this list fits on one page of a contract or order:

• The results of the 50-ticket test for both options, ticket by ticket, with token counts and the date the model prices were read.
• Approval before every write: human approval on the agent tools that write or send anything, and a Send and Wait step before the write in the fixed steps.
• A closed list of tools: only the ones the process needs, no tool that deletes data, “Selected” in MCP Client Tool, read-only access to systems wherever reading is enough, and read tools limited to the data of the customer the ticket is about. The principles for granting agents permissions are on our page about AI agent implementation.
• A deliberately set Max Iterations limit, not the default 10 just because it was there.
• A log of tool calls: Return Intermediate Steps switched on and a place where those steps are stored.
• An error-handling workflow with an Error Trigger step and a deliberately set retention period for execution data — both are covered in our n8n guide.

One note on approval in the agent: the n8n documentation recommends describing the tools and the approval steps in the standing instruction to the model. That instruction is guidance, not a safeguard. The only safeguard is what works independently of the model: the approval step, the list of tools and the permissions in your systems.

What to do next

Ticket triage is one of the processes we automate at ploch.ai, usually as a first step before anything that talks to customers — why in that order is explained on our page about customer service automation. If you are wondering whether an agent will pay off in your process, get in touch — let us start with one type of ticket and a test on your own cases. What such a project looks like, from choosing the task to approvals, is described on our page about AI agent implementation.

Sources, as at 12 October 2026

• n8n Docs: AI Agent node — at least one tool required, Tools Agent since release 1.82.0; read on 12 October 2026.
• n8n Docs: Tools Agent — System Message, Max Iterations (10 by default), Return Intermediate Steps, Require Specific Output Format with a parser, memory; read on 12 October 2026.
• n8n Docs: human review for agent tools — approval and denial, channels, the system-prompt recommendation; read on 12 October 2026.
• n8n Docs: Text Classifier and Information Extractor — categories with descriptions, dropping unmatched tickets by default, ways of defining fields; read on 12 October 2026.
• n8n Docs: MCP Client Tool — the Tools to Include setting; read on 12 October 2026.
• n8n Docs: sub-workflows and executions — sub-workflow executions and manual runs do not use up the limit; read on 12 October 2026.
• Text Classifier node source code in the n8n repository on GitHub — a separate output for each category; read on 12 October 2026.
• n8n pricing — the definition of an execution and plan prices; read on 12 October 2026.
• n8n on GitHub: releases — 2.42.7 as the latest stable release on 12 October 2026.