AI Agent Recipes in n8n: Three Scenarios Broken Down

Agent nodes in n8n let you assemble a working agent without code, and that is also where things go wrong: people make an agent out of what should be an ordinary workflow. Here are three scenarios where the pairing earns its place.

One rule before the scenarios

The agent owns decisions, the workflow owns execution. Anything expressible as conditions belongs in nodes rather than inside the agent loop. It is cheaper, more predictable, and debuggable through the execution history rather than model logs.

The practical test: if you can draw the process as a flowchart in advance, you do not need an agent - see when an agent is needed.

Scenario 1. A first-line support agent

The task. An incoming message becomes either an answer or a handover to a person.

How it is built. A trigger on the incoming message, an agent node with two tools - knowledge base search and order lookup by number - then a branch: if the agent is confident, send the answer; if not, create a task for a human.

What this gets right:

• Sending is outside the agent. It drafts the text; a separate node sends it. That lets you check the result before it goes out and log what actually left.
• Two tools, not ten. The agent does not get lost choosing.
• There is an explicit “I do not know” exit. Without one the agent invents an answer instead of admitting the data is missing.

What breaks in practice. The agent answers confidently on questions the knowledge base does not cover. The fix is not prompting but a threshold: if the search returned nothing, the branch goes to a human regardless of what the agent wrote.

Scenario 2. A classifier agent

The task. Sort incoming email into categories and assign priority.

No agent is needed here. This is a single model call with a structured response: text in, category and priority out. There is no loop and nothing to decide along the way.

The scenario is included precisely as an example of overengineering: classification is routinely built as an agent and costs several times more with no gain in quality.

The right way: a model node with a response schema, then ordinary branching nodes on the category. If no category was determined, that is its own branch rather than a guess.

The only case where an agent belongs here: when classification sometimes requires fetching data from another system. Then the loop is justified.

Scenario 3. An agent with database access

The task. Answer questions about the data: stock, statuses, summaries.

How it is built. An agent with a “run a database query” tool - and this is where the important part begins.

What is mandatory:

• Read-only rights. A dedicated database user with access to the tables required. Not because the agent is malicious but because it makes mistakes.
• A response size cap. An unbounded query returns thousands of rows, they enter context, and the next step becomes more expensive and worse.
• Prepared tools instead of arbitrary SQL. A “stock by product” tool is more reliable than “run any query”: the agent cannot get the structure wrong or build a heavy join.
• Calculations on the database side. An agent handed a thousand rows to sum them spends context and gets the arithmetic wrong.

Permissions and boundaries in detail: MCP security. The principles hold regardless of how the access is wired.

What to move out of the agent

A short list that improves almost any agentic workflow:

• Sending messages - a separate node after the agent.
• Writes into systems - likewise, with the result checked.
• Known routing - branching nodes.
• Formatting - plain expressions.
• Retries and error handling - the n8n mechanism, not the agent loop.

After that the agent holds exactly what it is for: interpreting unstructured input and deciding the ambiguous cases.

Base configuration of the agent nodes is in AI agents in n8n. Connecting external tools: MCP in n8n. The general theory is in the AI agents guide. The n8n overview is in the guide pillar.