n8n AI Nodes: Every AI Feature Explained
The AI Node System
n8n organizes its AI capabilities into over 70 specialized nodes built on LangChain. These nodes fall into seven categories: model nodes, agent nodes, chain nodes, memory nodes, vector store nodes, embedding nodes, and output parser nodes. Each category handles a specific part of the AI pipeline, and you combine them on the visual canvas to build complete AI workflows. Understanding what each category does and when to use it is essential for building effective AI automations in n8n.
Model Nodes
Model nodes connect your workflow to LLM providers. Each supported provider has its own node: OpenAI Chat Model, Anthropic Chat Model, Google Gemini Chat Model, Ollama Chat Model, Mistral Chat Model, Azure OpenAI Chat Model, and Cohere Chat Model. All model nodes expose the same interface to downstream nodes, so you can swap providers without changing the rest of your workflow.
Configuration options include model selection (GPT-4o, Claude 4, Gemini Pro, etc.), temperature, max tokens, and provider-specific settings. The Ollama Chat Model node connects to a locally running Ollama instance, enabling fully private AI workflows with no external API calls. Each model node also supports streaming output for real-time response display in chat interfaces.
Agent Nodes
The AI Agent node is the most complex and capable AI component in n8n. It implements LangChain agent types including ReAct (reason and act) and OpenAI Functions calling. The agent takes a goal or user message, reasons about which tools to use, calls those tools, evaluates the results, and either responds or calls additional tools. This loop continues until the agent determines it has sufficient information to provide a final answer.
Tools are any n8n nodes that you bind to the agent. A Calculator node, an HTTP Request node that queries your CRM, a PostgreSQL node that looks up customer data, a Wikipedia node for research, or a custom Code node can all serve as tools. The agent receives descriptions of available tools and selects which ones to call based on the conversation context. You can bind up to dozens of tools to a single agent, though performance tends to degrade beyond 10 to 15 tools as the LLM struggles to select from too many options.
Agent configuration includes system prompts (which set the agent's persona and constraints), maximum iterations (to prevent infinite loops), and human-in-the-loop settings that require approval before executing certain tools. The last feature is important for production deployments where you want AI-assisted automation but need human oversight on actions like sending emails, updating databases, or making financial transactions.
Chain Nodes
Chain nodes implement pre-built LangChain patterns for common tasks. The Summarization Chain condenses long documents into shorter summaries. The QA Chain with Retriever combines a vector store retriever with an LLM to answer questions based on retrieved context (the core RAG pattern). The Sequential Chain runs multiple LLM calls in order, passing output from one step as input to the next.
Chains are simpler than agents because they follow a fixed execution path rather than making dynamic decisions about tool use. Use chains when the processing steps are predictable (always summarize, always retrieve then answer) and agents when the workflow needs to adapt based on the input (sometimes search the web, sometimes check a database, sometimes do both).
Memory Nodes
Memory nodes manage conversation history for multi-turn interactions. Buffer Memory stores the entire conversation history and passes it to the LLM with each new message. Window Memory keeps only the last N messages, reducing token usage for long conversations. Token Buffer Memory tracks token count and drops older messages when a threshold is reached.
For persistent memory that survives across workflow executions, n8n provides database-backed memory nodes. PostgreSQL Chat Memory, Redis Chat Memory, and Motorhead Memory store conversation history externally, allowing users to resume conversations after the workflow has ended and restarted. This is critical for chatbot and customer support use cases where conversations span multiple sessions.
Vector Store Nodes
Vector store nodes connect to vector databases for semantic search and RAG. Supported databases include Pinecone, Qdrant, Weaviate, Supabase pgvector, Azure AI Search, Redis (with vector module), and an In-Memory Vector Store for testing. Each node operates in two modes: insert (for ingestion pipelines that add documents to the store) and search (for retrieval pipelines that query the store).
When used with a Vector Store Retriever sub-node, vector store nodes provide the retrieval component of RAG pipelines. The retriever queries the vector database with the user's input, returns the most similar document chunks, and passes them to the LLM as context for generating responses.
Embedding Nodes
Embedding nodes generate vector representations of text for storage in vector databases. OpenAI Embeddings, Cohere Embeddings, HuggingFace Embeddings, and Ollama Embeddings are the available options. The embedding model must match between ingestion and retrieval, so if you embed documents with OpenAI text-embedding-3-small, you must query with the same model.
For self-hosted setups, Ollama Embeddings with the nomic-embed-text model provides a free, private alternative to cloud embedding APIs. The quality is competitive with cloud options for most use cases, though specialized tasks like code search or multilingual retrieval may benefit from dedicated cloud models.
Output Parser Nodes
Output parser nodes structure raw LLM text output into specific formats. The Structured Output Parser extracts JSON objects matching a schema you define. The Auto-fixing Output Parser retries the LLM call if the output does not match the expected format. The List Output Parser extracts comma or newline-separated lists from LLM responses.
Output parsers are essential for workflows where downstream nodes need structured data rather than free text. If an AI agent needs to extract a customer name, order number, and issue category from a support ticket, an output parser ensures the result is a clean JSON object that other nodes can process reliably.