Go Deeper 7 min read Updated Sep 10, 2026

AI Agents in n8n

Everything up to this point has been deterministic: you decide exactly what runs next, using IF branches and Switch nodes. An AI agent flips that - instead of you hard-coding the logic, a language model decides which tool to use and when, based on the request it's given. n8n builds this on top of LangChain, with over 70 native nodes for agents, memory, vector stores, and model providers.

The AI Agent node

The AI Agent node is the core building block. Configure it with a connected chat model (OpenAI, Anthropic's Claude, Google Gemini, or a local model), a system prompt describing its role, and a set of tools it's allowed to use. When it runs, the model reasons about the incoming request and decides, on its own, which tools to call and in what order - rather than following a path you drew in advance.

Version note: the AI Agent node's configuration changed in 2026 - the older "agent type" dropdown some tutorials walk through has been deprecated in favor of a simpler, more direct tool-and-model setup. If a guide references picking an agent type and your version doesn't show that option, this is why.

Tools: what the agent is actually allowed to do

A tool in n8n is just another workflow (via the Execute Workflow node, covered earlier) or a specialized node - like an HTTP Request, a Vector Store lookup, or a Code node - wrapped so the agent can decide to invoke it. This is the same sub-workflow pattern from the reusability guide, applied to giving an LLM real capabilities: "search our knowledge base," "look up an order," "send a Slack message," each as a discrete, callable tool the model chooses from.

Memory: giving the agent context across turns

By default, each agent run is stateless - it only sees what's in the current request. Attach a Memory node (buffer memory, or a database-backed memory for persistence across sessions) to let the agent remember earlier messages in a conversation, which matters for anything built as a chat interface rather than a single one-shot request.

Model providers, including Claude

n8n's chat model nodes support most major providers - OpenAI, Anthropic Claude, Google Gemini (a Gemini node with multimodal support shipped in early 2026), and self-hosted/local models. Swapping providers is usually a matter of changing which chat model node feeds into the AI Agent, without rebuilding the rest of the workflow. The next guide in this series goes deeper on connecting Claude specifically, including where MCP fits in.

A realistic starting agent

A good first build: a support-ticket triage agent. Trigger on a new email or webhook, feed the message into an AI Agent node with two tools - a vector store lookup over your help docs, and a "create ticket" sub-workflow - and let the model decide whether to answer directly from the docs or escalate to a human. That single pattern (route, retrieve, decide, act) covers a large share of real-world agent use cases.

Where this differs from a plain workflow: in a normal workflow, you decide the path. In an agent, the model decides the path, choosing from the tools you've made available - which is more flexible, but also means testing an agent means testing a range of inputs, not just one.
Next up: connecting Claude specifically as your agent's model, and where MCP fits into an n8n workflow.
Share this guide

Was this guide helpful?

Thanks for the feedback!

Want more hands-on AI builds like this?

APA Mastery runs live, practical sessions on working with modern AI tools - not just theory.

See What's On →
← PreviousSelf-Hosted vs Cloud