n8n AI Agent Node: Guide 2026

Aktualisiert: 4. Juli 2026

Der n8n AI Agent Node ist ein LangChain-basierter Baustein, mit dem du in n8n einen LLM-Agenten erstellst, der eigenständig Tools aufruft, Kontext speichert und mehrstufige Aufgaben löst, ohne eine Zeile Backend-Code. Seit der stabilen LangChain-Integration Anfang 2024 hat sich der Node zu einem der pragmatischsten Wege entwickelt, um Chat-Modelle, Vektorspeicher und externe APIs in einem einzigen visuellen Workflow zu verdrahten. In diesem Guide zeige ich dir, wie ich AI-Agent-Workflows produktionsreif aufsetze, welche Fallstricke ich mir schon eingefangen habe (mehrfach, ehrlich gesagt) und wann n8n eine schlechtere Wahl ist als reiner Code.

Der AI Agent Node basiert auf LangChain.js und unterstützt seit 2025 stabile Tool-Calling-Modelle wie GPT-4o, Claude 3.5/4 und Gemini 2.0.
Ein produktionsreifer Agent besteht aus vier Bausteinen: Chat Model, Memory, mindestens einem Tool und einem Trigger, alles über Sub-Nodes verkabelt.
Selbst gehostetes n8n auf Docker/Kubernetes kostet unter 20 € pro Monat und erlaubt beliebig viele Agent-Executions ohne Vendor-Aufschlag.
Memory-Nodes (Buffer Window, Postgres, Redis) entscheiden über Kohärenz. Ohne persistente Memory verlieren Agenten nach jedem Trigger den Kontext.
Für hochsensible Daten oder komplexe Verzweigungslogik ist ein handgeschriebener LangGraph- oder Semantic-Kernel-Agent belastbarer als ein n8n-Flow.

Was ist der n8n AI Agent Node?

Der AI Agent Node ist n8ns hauseigene Umsetzung eines LangChain-Agenten. Anstatt einen Prompt an ein Chat-Modell zu schicken und die Antwort selbst zu parsen, übergibst du dem Agent-Node ein Ziel plus eine Liste von Tools. Der Agent entscheidet dann selbst, welches Tool er in welcher Reihenfolge aufruft, bis das Ziel erreicht ist. Die Ausführung folgt intern einer ReAct- oder Tool-Calling-Schleife, je nach gewähltem Modell.

Praktisch heißt das: Du hängst als Sub-Nodes ein Chat-Modell (OpenAI Chat Model, Anthropic Chat Model, Google Gemini, Ollama, Groq; die Liste wächst mit jedem Release), optional einen Memory-Speicher und beliebig viele Tools an den Agent-Node an. Ein Tool kann alles sein: ein HTTP-Request, ein Google-Sheets-Zugriff, eine SQL-Abfrage, ein anderer n8n-Workflow oder ein Vector-Store-Retriever. Der Node ist seit n8n 1.19 stabil und wird laufend erweitert. Im Frühjahr 2026 kamen zum Beispiel native Streaming-Ausgabe und ein "Think Tool" für Reasoning-Modelle dazu.

Was den Node von einer klassischen LangChain-Skriptdatei unterscheidet, ist die visuelle Verkabelung. Kolleg:innen aus Ops oder Marketing können einen bestehenden Agenten inspizieren, Tools tauschen oder die Systemnachricht umschreiben, ohne sich in TypeScript einzuarbeiten. Genau das war für mich beim Umstieg aus reinen Code-Pipelines das entscheidende Argument.

Architektur eines n8n-Agenten

Jeder produktionsreife AI-Agent-Flow in n8n besteht aus fünf Schichten, die konsequent voneinander getrennt werden sollten. Ich erkläre sie in Ausführungsreihenfolge.

Trigger: Webhook, Schedule, Chat-Trigger oder ein eingehender E-Mail-Event. Der Trigger definiert, wann der Agent aufwacht und welche Rohdaten er sieht.
Preprocessing: Set-Nodes normalisieren Eingaben, extrahieren die eigentliche Frage und schreiben Metadaten (User-ID, Session-ID) in ein einheitliches Schema.
AI Agent Node: Das Herzstück, mit Sub-Nodes für Modell, Memory und Tools. Hier steckt die Systemnachricht mit Rolle, Grenzen und Antwortformat.
Postprocessing: Validierung der Ausgabe (JSON-Schema, Guardrails), Logging in eine Datenbank, ggf. Übersetzung oder Formatierung.
Response/Side-Effect: Antwort an den Webhook-Aufrufer, Slack-Nachricht, Ticket-Update oder Datenbank-Insert.

Diese Trennung klingt trivial, spart aber massiv Zeit im Debugging. Wenn ein Kunde meldet "der Bot halluziniert", liegt der Fehler in 80 % der Fälle im Preprocessing (falsche Kontext-Extraktion) oder Postprocessing (Antwort wird ungeprüft weitergereicht), nicht am Modell selbst. Ein sauber geschnittener Flow zeigt dir in der n8n-Execution-Ansicht binnen Sekunden, wo es gebrannt hat. Ich hab das erst kürzlich in einem Support-Bot erlebt: die vermeintliche Halluzination stammte aus einem Set-Node, der einen leeren String durchreichte, nicht aus GPT-4o.

Schritt-für-Schritt: Ersten Agenten bauen

Für dieses Tutorial baust du einen Support-Agenten, der eingehende Fragen beantwortet, indem er in einer Postgres-Wissensdatenbank sucht und bei fehlender Information ein Ticket in Linear anlegt. Voraussetzungen: eine laufende n8n-Instanz (Cloud oder self-hosted ab Version 1.60), API-Keys für OpenAI oder Anthropic und Zugriff auf eine Postgres-Datenbank.

1. Trigger und Systemnachricht

Lege einen neuen Workflow an, füge einen Chat Trigger ein und aktiviere "Public URL". Verbinde ihn mit einem AI Agent Node. Wähle als Agent-Typ "Tools Agent". Der nutzt natives Tool-Calling und ist deutlich zuverlässiger als der klassische ReAct-Agent. In der Systemnachricht formulierst du Rolle und Regeln:

Du bist der Support-Agent für Acme SaaS. Beantworte Fragen ausschließlich
auf Basis der Ergebnisse aus dem Tool "knowledge_search". Wenn keine
Information gefunden wird, rufe "create_ticket" auf und teile dem
Nutzer die Ticket-ID mit. Antworte prägnant auf Deutsch.
Erfinde niemals Produktfeatures oder Preise.

2. Chat-Modell verkabeln

Hänge einen OpenAI Chat Model-Sub-Node an. In Produktion setze ich meist auf gpt-4o-mini für hohe Volumina und claude-sonnet-4 für komplexere Reasoning-Aufgaben. Setze temperature auf 0.2. Höhere Werte machen Tool-Calls unzuverlässiger, das hab ich in einem A/B-Test mit rund 400 Sessions selbst gemessen.

3. Memory-Sub-Node

Verbinde einen Postgres Chat Memory-Node. Als Session-Key nutzt du {{ $json.sessionId }}. Damit erinnert sich der Agent an den bisherigen Verlauf einer Konversation, überlebt aber auch n8n-Restarts. Ein häufig unterschätzter Vorteil gegenüber dem simplen Buffer-Memory.

4. Zwei Tools anbinden

Das erste Tool ist ein Vector Store Tool, das auf einen bestehenden pgvector-Index zeigt. Beschreibung: "Sucht in der Produktdokumentation nach Antworten auf Nutzerfragen." Das zweite Tool ist ein HTTP Request Tool, das die Linear-API mit einem POST auf /graphql aufruft. Wichtig: In der Tool Description beschreibst du präzise, wann der Agent das Tool nutzen soll. Schlechte Beschreibungen sind Ursache Nummer eins für falsch ausgewählte Tools.

Tools und externe APIs anbinden

Der AI Agent Node akzeptiert drei Arten von Tools: eingebaute Utility-Tools (Rechner, Wikipedia, Serper), Node-basierte Tools und Custom Workflow Tools. Node-basierte Tools sind der Regelfall. Jeder n8n-Node (Google Sheets, Slack, Airtable, HTTP Request, HubSpot …) lässt sich als Tool markieren und wird dem Agenten automatisch mit Parametern zur Verfügung gestellt.

Besonders mächtig sind Custom Workflow Tools. Damit ruft der Agent einen anderen n8n-Workflow als Sub-Routine auf. In der Praxis heißt das: Du kapselst komplexe Multi-Step-Logik (etwa "Rechnung erzeugen, an DATEV übergeben, Buchhaltung notifyen") in einen eigenen Workflow und exponierst ihn als einzelnes Tool namens create_invoice. Der Agent muss dann nur wissen, wann er die Rechnung erstellt, nicht wie. Diese Delegation hält Systemnachrichten kurz und Debugging planbar.

Bei HTTP-Request-Tools gebe ich dem Agenten immer nur Endpunkte, die idempotent sind oder ein Dry-Run-Flag akzeptieren. Ein Agent, der versehentlich zweimal auf DELETE /users/42 feuert, wird schnell teuer. Wer tiefer in agentische Tool-Patterns einsteigen will, findet in unserem Vergleich LangGraph vs CrewAI vs AutoGen eine Übersicht der Code-basierten Alternativen zu n8n.

Beispiel: HTTP Request Tool für Linear

POST https://api.linear.app/graphql
Headers:
  Authorization: {{ $credentials.linearApi.token }}
  Content-Type: application/json
Body (JSON):
{
  "query": "mutation ($input: IssueCreateInput!) { issueCreate(input: $input) { issue { id identifier } } }",
  "variables": {
    "input": {
      "teamId": "TEAM_UUID",
      "title": "{{ $fromAI('title', 'Kurzer Ticket-Titel') }}",
      "description": "{{ $fromAI('description', 'Ausführliche Fehlerbeschreibung') }}"
    }
  }
}

Der Ausdruck $fromAI() ist eine der wichtigsten Neuerungen von 2025: Er sagt dem Agenten explizit, welche Argumente er ableiten muss, inklusive Beschreibung und optionalem Typ. Ohne $fromAI hätte der Agent keinerlei Anleitung, wie er Parameter für dein Tool erzeugen soll.

Memory-Optionen im Vergleich

Memory ist der Bereich, in dem ich beim Umstieg von Prototyp zu Produktion am häufigsten refactoren muss. n8n bietet fünf Speicheroptionen, die sich in Persistenz, Kosten und Skalierbarkeit deutlich unterscheiden.

Memory-Node	Persistent	Latenz	Empfohlen für
Buffer Memory	Nein (nur im Prozess)	< 1 ms	Prototypen, Einzelanfragen
Buffer Window Memory	Nein	< 1 ms	Kurze Chats mit N letzten Turns
Redis Chat Memory	Ja	1–5 ms	Skalierbare Chatbots, Session-Store
Postgres Chat Memory	Ja	5–20 ms	Produktion mit Audit-Anforderungen
MongoDB Chat Memory	Ja	5–15 ms	Bestehende MongoDB-Infrastruktur

Buffer-Memory verliere ich bei jedem n8n-Restart und bei horizontaler Skalierung. Postgres nutze ich, wenn die Konversationshistorie für Compliance ohnehin persistiert werden muss. Dann spare ich mir eine zweite Speicherschicht. Redis ist mein Default für Kundenprojekte mit > 1000 aktiven Sessions pro Tag; das TTL-Handling ist trivial und Redis überlebt Loadspitzen locker.

Ein häufig übersehener Punkt: Die Kontextfenster von GPT-4o oder Claude Sonnet sind zwar groß, aber jeder Token kostet. Setze deshalb bei Buffer-Window-Memory die Turn-Anzahl auf 6–10 und komprimiere ältere Nachrichten über einen zusätzlichen Summarization-Agent, wenn die Konversation länger wird. Für Kostenoptimierung bei Anthropic-Modellen lohnt sich der Blick in unseren Praxis-Guide zu Anthropic Prompt Caching.

n8n vs Zapier vs Make für KI-Workflows

Die häufigste Frage, die ich in Discovery-Calls höre: "Warum n8n und nicht Zapier oder Make?" Alle drei haben inzwischen AI-Agenten-Funktionen, unterscheiden sich aber deutlich in Architektur und Kostenmodell.

Kriterium	n8n	Zapier	Make.com
Self-Hosting	Ja (Fair-Code-Lizenz)	Nein	Nein
AI-Agent-Konzept	LangChain-Nodes, Multi-Tool	Zapier AI Actions	OpenAI/Anthropic Module
Preismodell	Executions oder self-hosted flat	Tasks pro Monat	Ops pro Monat
Custom Code	JavaScript & Python nativ	Code-Steps limitiert	Nur JavaScript
Anzahl Integrationen	~500 (Stand 2026)	> 7000	> 2000
Debugging	Volle Execution-Historie	Task-History pro Zap	Execution-Log pro Szenario
Beste Nische	Technische Teams, Datenhoheit	Business-Automation ohne Dev	Visuelle Ops-Modellierung

Mein Entscheidungsraster: Wenn Datenhoheit, Kostenkontrolle bei hohem Volumen oder mehrstufige Agenten mit eigenen Tools im Fokus stehen, gewinnt n8n. Für Marketing- und Sales-Teams, die schnell drei Trigger und zwei Actions verkabeln wollen, ist Zapier weiterhin unschlagbar. Make.com hat die eleganteste Verzweigungslogik, hinkt aber bei nativen Agenten-Nodes hinterher.

Produktionsreife: Fehlerbehandlung, Kosten, Monitoring

Ein n8n-Agent, der lokal läuft, ist noch kein Produktionsagent. Ich habe genug Postmortems gelesen, in denen genau diese Distinktion zum Ausfall führte. Drei Aspekte müssen sitzen.

Fehlerbehandlung

Aktiviere unter Workflow-Settings den Error-Workflow-Trigger und lege einen separaten Workflow an, der Fehler in Sentry oder Slack meldet. Wichtiger noch: In jedem HTTP-Request-Tool setzt du Retry On Fail mit Backoff und begrenzt Max Tool Iterations im AI-Agent-Node auf einen sinnvollen Wert (bei mir meist 8). So kann der Agent nicht in einer Endlosschleife stecken bleiben und dein LLM-Budget aufessen.

Kostenkontrolle

Jeder Tool-Call bedeutet mindestens einen Modell-Call zum Entscheiden plus einen Modell-Call zum Verarbeiten der Tool-Antwort. Ein Agent mit fünf Iterationen kostet dich bei GPT-4o um die 0,03–0,05 € pro Session. Klingt wenig, aber bei 50 000 Sessions im Monat sind das 1 500 bis 2 500 €. Zwei Hebel senken das drastisch: (1) Wechsel auf kleinere Modelle (gpt-4o-mini, Claude Haiku) für einfache Anfragen und (2) Router-Pattern, in dem ein günstiges Klassifikationsmodell entscheidet, ob überhaupt ein Agent nötig ist oder ob eine Regel greift.

Monitoring

n8ns Execution-Historie zeigt dir Trace-Daten pro Node, aber für LLM-spezifische Metriken (Token-Cost, Halluzinationsrate, Tool-Erfolgsquote) brauchst du ein dediziertes Tracing-Tool. Ich exportiere die Agent-Ausgaben über einen zusätzlichen HTTP-Node an Langfuse. Details dazu im Deep-Dive LLM Observability mit Langfuse. Alternativ funktionieren OpenTelemetry-basierte Kollektoren auch mit n8n über den generischen HTTP-Exporter.

Wann n8n an seine Grenzen stößt

Ich bin Fan von n8n, aber nicht dogmatisch. Es gibt drei Szenarien, in denen ich Teams zu einem code-first-Ansatz rate.

Komplexe State-Machines: Sobald ein Agent zyklische Übergänge, Human-in-the-Loop-Pausen über Stunden oder Tage und paralleles State-Merging braucht, wird ein n8n-Flow schnell unübersichtlich. Dann greife ich zu LangGraph oder Semantic Kernel.
Strikte Compliance mit granularen Audit-Trails: n8n loggt pro Execution, nicht pro Tool-Call auf Feldebene. Wer BAIT-, HIPAA- oder FedRAMP-konforme Trace-Logs braucht, sollte den Agent-Kern in Python schreiben und nur die Ränder in n8n orchestrieren.
Sub-Sekunden-Latenz für interaktive Agenten: Der n8n-Executor hat einen Overhead von 100–300 ms pro Node. Bei Voice-Agents oder Realtime-Chatbots kann das den Unterschied zwischen "responsiv" und "träge" ausmachen. Latenzkritische Kernpfade laufen dann in einem eigenen Node-Service; n8n orchestriert nur Batch-Schritte.

Umgekehrt gilt: Für 80 % aller B2B-Automatisierungen mit Freitext-Input, Tool-Aufrufen und asynchronen Antworten in Sekunden statt Millisekunden bin ich mit n8n schneller in Produktion als mit jedem Code-Framework, bei besserer Übergabe an Kolleg:innen, die keine LangChain-Interna kennen. Die offizielle n8n Advanced AI-Dokumentation und das LangChain.js Agents-Tutorial sind die beiden Referenzen, die ich immer offen habe.

Häufig gestellte Fragen

Ist n8n wirklich kostenlos nutzbar?

Ja. n8n ist unter der Fair-Code-Lizenz (Sustainable Use License) self-hostbar und für interne Automatisierung ohne Lizenzkosten. Die n8n-Cloud-Variante ist ein bezahltes Managed Hosting; für eigene Workflows ohne Weiterverkauf zahlst du nur die zugrundeliegenden Modell- und Infrastrukturkosten.

Welche LLMs unterstützt der n8n AI Agent Node 2026?

Stand Mitte 2026 laufen offiziell OpenAI (GPT-4o, GPT-4.1, o-Serie), Anthropic (Claude Sonnet 4, Haiku 4.5, Opus 4), Google Gemini 2.0/2.5, Groq, Mistral, xAI Grok, Cohere und selbstgehostete Modelle über Ollama oder LM Studio. Die Sub-Node-Auswahl heißt "Chat Model" und wird pro Release erweitert.

Wie unterscheiden sich Tools Agent, ReAct Agent und Plan-and-Execute Agent?

Der Tools Agent nutzt natives Function-Calling der modernen LLMs und ist heute die stabilste Wahl. Der ReAct Agent schreibt Reasoning und Aktionen als Text, nützlich für Modelle ohne Tool-Calling. Plan-and-Execute erzeugt erst einen mehrstufigen Plan und arbeitet ihn dann ab; teurer, aber besser bei komplexen Aufgaben mit vielen Zwischenschritten.

Kann ich n8n-AI-Workflows mit RAG kombinieren?

Absolut. n8n hat native Nodes für Qdrant, Pinecone, Supabase pgvector, Weaviate und Milvus. Du hängst einen Vector-Store-Node als Tool an deinen Agent oder baust eine separate Retrieval-Chain vor dem Agent-Node. Für Best Practices siehe unseren Guide zur Optimierung von RAG-Pipelines mit Hybrid Search und Reranking.

Wie deploye ich n8n produktiv auf eigener Infrastruktur?

Der Standard ist Docker Compose mit n8n, Postgres und Redis als Queue-Mode-Backend. Für höhere Last skaliert Kubernetes mit dediziertem Worker-Deployment. Wichtig: aktiviere Queue Mode über die Umgebungsvariable EXECUTIONS_MODE=queue, sonst blockiert eine lange Agent-Iteration deinen Main-Prozess.