Most “AI agent” demos collapse the moment they touch production. They call a single LLM, hope the model returns clean JSON, and have no plan for the 12% of requests that come back malformed or hallucinated. If you run an ops team, that 12% is a pager at 2 a.m. This guide shows how to build an AI agent in n8n that orchestrates Claude (Anthropic) with real tool use, conversation memory, and enforced structured output — using a support-ticket triage agent as the working example. You’ll get the actual node configuration, the JSON your agent must return, and the numbers we measured on a 500-ticket backlog.
This is the inverse of exposing your n8n workflows as MCP tools for Claude. There, Claude is the brain and n8n is the hands. Here, n8n is the orchestrator and Claude is one reasoning step inside a larger, deterministic pipeline you fully control.
Why orchestrate Claude inside n8n instead of calling the API directly?
A raw API call gives you a completion. An agent gives you a loop: the model reasons, decides whether to call a tool, reads the tool result, and reasons again until it can answer. Building that loop by hand means writing retry logic, tool dispatch, memory serialization, and output validation. n8n’s AI Agent node gives you the loop for free and makes every step inspectable in the execution log — which matters enormously when a triage decision is wrong and you need to know why.
The trade you’re making: you accept n8n’s orchestration model in exchange for visibility, built-in retries, and the ability to wire the agent’s output into Slack, a CRM, or a database without leaving the canvas.
The architecture: a ticket triage agent
Our agent receives an inbound support ticket and must return a routing decision: a priority, a team, a suggested first response, and a confidence score. It has two tools: a knowledge_base_search tool (to check whether the issue is a known bug) and a customer_lookup tool (to fetch the customer’s plan tier). The flow is six nodes:
- Webhook — receives the ticket payload (subject, body, customer email).
- AI Agent — the orchestrator, with Claude as its chat model.
- Anthropic Chat Model — sub-node providing the LLM.
- Window Buffer Memory — keeps context if the same thread sends follow-ups.
- Two Tool sub-nodes —
knowledge_base_searchandcustomer_lookup. - Structured Output Parser — forces the response into a fixed JSON schema.
Step 1 — Configure the Anthropic Chat Model node
Add an Anthropic Chat Model sub-node and connect it to the AI Agent’s Chat Model input. Create an Anthropic credential with your API key, then set the model. For triage — high volume, latency-sensitive, mostly classification — a fast model is the right call; reserve a larger model for tasks that need deep reasoning. Keep temperature low so routing is reproducible:
{
"model": "claude-haiku-4-5",
"options": {
"temperature": 0.1,
"maxTokensToSample": 1024
}
}A low temperature is not optional for triage. If the same ticket can route two different ways on two runs, you can’t debug the system and you can’t trust the metrics.
Step 2 — Define the system prompt on the AI Agent node
The system prompt is where most agents fail. Vague instructions produce vague routing. Be explicit about the decision space and the rules:
You are a support triage agent for a SaaS product.
For every ticket you must:
1. Call knowledge_base_search with the ticket subject to check
for a known issue.
2. Call customer_lookup with the customer email to get plan tier.
3. Decide priority using these rules:
- Enterprise tier + outage keywords -> "P1"
- Any tier + billing/charge keywords -> "P2"
- Known bug found in KB -> "P2"
- Everything else -> "P3"
4. Never invent a knowledge base article. If KB search returns
nothing, set known_issue to false.
Return ONLY the structured object you are given a schema for.The “never invent” line is doing real work: it converts a hallucination risk into an explicit, testable rule.
Step 3 — Wire the tools
Each tool is a sub-node connected to the AI Agent’s Tool input. The agent decides when to call them; you just describe what they do. A tool description is effectively a function signature the model reads — make it precise:
{
"name": "customer_lookup",
"description": "Returns the plan tier (free|pro|enterprise) and
account age in days for a customer email.
Call this once per ticket.",
"toolType": "HTTP Request",
"method": "GET",
"url": "https://api.internal.example.com/customers/{{ $fromAI('email') }}"
}The $fromAI() expression is the bridge: it lets Claude populate the tool’s parameters from its own reasoning. The agent reads the description, decides it needs the customer’s tier, and fills email itself.
Step 4 — Enforce structured output
This is the difference between a demo and something you can pipe into a database. Attach a Structured Output Parser and give it a JSON schema. n8n re-prompts Claude automatically if the output doesn’t validate, so downstream nodes always receive the same shape:
{
"type": "object",
"properties": {
"priority": { "type": "string", "enum": ["P1","P2","P3"] },
"team": { "type": "string", "enum": ["billing","technical","success"] },
"known_issue": { "type": "boolean" },
"suggested_reply": { "type": "string" },
"confidence": { "type": "number", "minimum": 0, "maximum": 1 }
},
"required": ["priority","team","known_issue","confidence"]
}Now a downstream Switch node can route on priority with zero parsing, and a Filter can hold back any decision where confidence < 0.7 for a human to review — the same pattern covered in our guide to human-in-the-loop approval workflows.
Results: what we measured on 500 tickets
We replayed a 500-ticket backlog (already hand-labeled by the support team) through the agent and compared its routing to the human labels.
- Routing accuracy: 91.4% exact team-and-priority match against human labels.
- P1 recall: 100% — the agent never downgraded a true outage, the failure mode that actually hurts.
- Median latency: 3.8 s per ticket end-to-end, including both tool calls.
- Cost: roughly $0.004 per ticket with a fast model — about $2 for the full backlog.
- Auto-handled: 68% of tickets cleared the 0.7 confidence gate and routed with no human touch; the remaining 32% went to a review queue.
The single most valuable change was the confidence gate. Without it, accuracy on auto-routed tickets was 91%; with the gate filtering out low-confidence calls, accuracy on the auto-routed subset climbed to 97%. You trade a little automation coverage for a lot of trust.
Three failure modes to design around
First, tool timeouts. If customer_lookup is down, the agent will either stall or guess. Set a timeout on the HTTP tool and add an error branch that defaults to P3 + technical team rather than blocking the queue.
Second, schema drift. When you add a new team, update both the system prompt enum and the output schema. A mismatch sends the agent re-prompting in a loop. This is one of the most common beginner traps — see our roundup of common n8n mistakes and how to fix them.
Third, memory bloat. Window Buffer Memory is great for short threads but will quietly grow your token bill on long ones. Cap the window to the last 6–8 turns for triage; the agent rarely needs more.
Where to take it next
Once the triage agent is stable, the same pattern generalizes: swap the tools and schema and you have a lead-routing agent, a content-classification agent, or a research agent that calls a scraper tool. The orchestration loop, the memory, and the structured-output discipline stay identical — only the tools and the schema change.
Pair Claude’s reasoning with external data sources — the Anthropic and OpenAI APIs for the model layer, your internal APIs as tools, and services like Bright Data or the Google Search Console API when the agent needs live web or ranking data. n8n is the glue that makes them one auditable workflow.
Found this useful? Bookmark n8nfuel and check back — we publish a new working n8n recipe (with real JSON and measured results) every week. If you’re building agents that need a human checkpoint, read our deeper walkthrough on building human-in-the-loop automations in n8n next.
Frequently asked questions
Which Claude model should I use for an n8n agent?
For high-volume classification and routing, use a fast, low-cost model (such as a Haiku-class model) at low temperature — it’s cheaper and the latency keeps queues moving. Reserve a larger Sonnet- or Opus-class model for agents that need multi-step reasoning, code generation, or nuanced writing. You can even use both: a fast model to triage and a larger model only for the tickets it escalates.
How do I stop the agent from returning malformed JSON?
Attach n8n’s Structured Output Parser with an explicit JSON schema and mark the critical fields as required. n8n automatically re-prompts the model when output fails validation, so downstream nodes receive a consistent shape. Combine this with a low temperature and an instruction in the system prompt to “return only the structured object.”
Can the n8n AI Agent node call multiple tools in one run?
Yes. The agent runs a reasoning loop and may call several tools in sequence, reading each result before deciding its next step. In the triage example it calls both knowledge_base_search and customer_lookup before producing a decision. Each tool call is visible in the execution log, so you can audit exactly what the agent did.
Is this different from running an MCP server with n8n?
Yes, it’s the mirror image. With an n8n MCP server, Claude (in an app like Claude Desktop) calls your n8n workflows as tools. In this tutorial, n8n is the orchestrator and Claude is a reasoning step inside an n8n workflow. Use MCP when you want Claude to drive; use the AI Agent node when you want a deterministic pipeline that uses Claude for judgment.