n8n KI-Agent-Workflows: 5 Production-Patterns aus dem Live-Betrieb

Ich betreibe n8n produktiv für Content-Operations, E-Mail-Triage und Rechnungsverarbeitung. Die visuelle Canvas-Oberfläche ist nicht der Kern. Der Kern ist, dass Trigger, Retries, Queues und Credentials kostenlos mitkommen — und dass ich einen Workflow an Nicht-Engineers übergeben kann, die Prompts editieren, ohne die Integrationsschicht zu zerlegen.

Dieser Beitrag zeigt fünf n8n-KI-Agent-Workflows, die ich aktuell ausliefere oder für Kunden ausgeliefert habe. Jeder enthält den Node-Graphen, den Claude-Prompt, die Kosten pro Run und die produktiven Stolpersteine. Keine Spielzeug-Demos.

Wenn Sie noch zwischen Plattformen entscheiden, deckt mein Make-vs-n8n-Vergleich für Produktivlasten den Tradeoff ab. Dieser Beitrag setzt voraus, dass Sie n8n bereits gewählt haben.

Warum n8n für KI-Workflows

Einen Agent in reinem Python oder TypeScript zu schreiben ist legitim. Bei vielleicht 60 Prozent der Aufgaben, die ich sehe, ist es trotzdem die falsche Wahl. Hier gewinnt n8n:

Trigger sind kostenlos. Gmail, Slack, Webhooks, IMAP, Schedule, Telegram, Airtable, Postgres-Row-Change. In Code würden Sie jeden davon selbst verkabeln. In n8n ist es ein Dropdown.

Retries und Error-Branches sind nativ. Jeder Node hat eine Retry-Konfig und einen Error-Output. Ich muss nicht jeden API-Call in try/except wickeln.

Credentials sind ein First-Class-Objekt. Ich versehentlich keine API-Keys in Git. Credentials liegen verschlüsselt in n8n und werden zur Laufzeit injiziert.

Human-in-the-Loop ist billig. Telegram-Node, Gmail-Node oder ein Wait-for-Webhook-Pattern lassen einen Run pausieren, einem Menschen einen Entwurf schicken und auf Freigabe weiterlaufen. In Code wäre das ein Wochenende. In n8n vier Nodes.

LangChain-Nodes sind eingebaut. Die n8n-LangChain-Integration liefert Agent-Nodes, Memory Buffers, Vector-Store-Retriever und Tool-Bindings out-of-the-box. Sie können RAG in sechs Nodes umsetzen, ohne selbst LangChain-Code zu schreiben.

Business-User können Prompts editieren. Das ist der eigentliche Gewinn. Meine Kunden editieren den Claude-System-Prompt, ohne die Integration anzufassen. Der Engineer verkabelt die Pipeline einmal, der Business-Owner besitzt den Prompt.

Wo Code dennoch gewinnt: Ultra-Low-Latency-Chat-UIs, komplexe Agent-Loops mit mehr als fünf Tool-Calls pro Turn und schwere Datei-Verarbeitungs-Pipelines. Mehr dazu am Ende.

Das Pattern hinter allen 5 Workflows

Jeder produktive KI-Workflow, den ich in n8n betreibe, folgt derselben Form:

Trigger > Input normalisieren > Klassifizieren (Haiku) > Branch > Generieren (Sonnet) > Aktion > Loggen

Die Schlüsselbewegungen:

1. Haiku zum Klassifizieren, Sonnet zum Generieren. Haiku ist rund 10× günstiger als Sonnet. Nehmen Sie Haiku für Routing-Entscheidungen (“ist das dringend”, “welche Kategorie”, “ist das Spam”). Nehmen Sie Sonnet für die eigentliche Inhaltsarbeit. Modell-Tradeoffs vertieft mein Claude API Tool Use Guide.
2. Strukturierter Output via Tool Use, nicht freies JSON. Claude zu sagen “antworte in JSON” funktioniert meistens. Tool Use mit Schema funktioniert immer. Jedes Beispiel unten nutzt das Tool-Use-Pattern.
3. Jeder Workflow hat einen Error-Pfad. Fehlgeschlagene Executions route ich auf Telegram, damit ich sofort davon höre. Stilles Versagen ist die Todesart von Agenten in der Produktion.
4. Token-Verbrauch wird geloggt. Jeder Run schreibt Input- und Output-Token-Count nach Postgres. Ohne das sehen Sie nicht, wenn ein Prompt über die Zeit länger wird und Ihre Rechnung steigt.

Mit diesem Gerüst, hier die fünf Workflows.

1. Eingehende E-Mail-Triage mit Claude

Problem: Mein Posteingang bekommt einen Mix aus Kundenanfragen, Rechnungen, Cold-Sales und Notifications. Manuelle Triage frisst 30 bis 45 Minuten am Tag. Ich will, dass der Posteingang sortiert ankommt, mit Entwürfen für das, was Antwort braucht.

Trigger: Gmail-Node (OAuth) pollt alle 5 Minuten. IMAP funktioniert auch, falls Sie kein OAuth einsetzen wollen.

Node-Graph:

Gmail Trigger > Code (Subject, Sender, Body, Attachments extrahieren)
 > Claude (Haiku, Tool Use) > Switch (nach Kategorie)
   > [Rechnungen]  Notion Create Page + Gmail Auto-Reply
   > [Support]     TickTick Create Task + Slack-Notify
   > [Vertrieb]    Gmail Forward + Slack-Notify
   > [Sonstiges]   Gmail Label "Später"
 > Postgres (Klassifikation + Token-Count loggen)

Claude-Node-Konfig. Hier nehme ich Haiku 4.5, weil Klassifikation günstig ist und ich 200 E-Mails am Tag verarbeite. System-Prompt plus Tool-Definition:

{
  "model": "claude-haiku-4-5-20251001",
  "system": "Du klassifizierst eingehende E-Mails. Gib genau eine Kategorie zurück. Stelle keine Rückfragen. Erfinde keine Fakten über den Absender.",
  "tools": [{
    "name": "classify_email",
    "description": "Klassifiziert die E-Mail und extrahiert Metadaten",
    "input_schema": {
      "type": "object",
      "properties": {
        "category": {"type": "string", "enum": ["invoice", "support", "sales", "other"]},
        "priority": {"type": "string", "enum": ["low", "medium", "high"]},
        "needs_response": {"type": "boolean"},
        "summary": {"type": "string", "maxLength": 200}
      },
      "required": ["category", "priority", "needs_response", "summary"]
    }
  }],
  "tool_choice": {"type": "tool", "name": "classify_email"}
}

Stolpersteine.

• Gmail-Trigger pollt. Wenn Sie Echtzeit brauchen, nutzen Sie Gmail-Push via Pub/Sub. Für die meisten Use Cases reicht 5-Minuten-Polling.
• Anhänge werden Claude per Default nicht übergeben. PDF-Text vorher extrahieren (siehe Workflow 5), sonst halluziniert das Modell den Inhalt.
• Error-Branch am Claude-Node auf Telegram routen. Wenn Rate-Limits zuschlagen, wollen Sie es wissen.

Kosten. Haiku 4.5 bei ~200 Tokens Input und ~80 Tokens Output pro E-Mail. Etwa 0,0002 $ pro Klassifikation. 200 E-Mails am Tag kosten rund 0,04 $. Vernachlässigbar.

2. Document-Q&A-Bot mit RAG (Qdrant + Claude)

Problem: Ein Kunde hat 400 PDF-Policy-Dokumente. Vertriebsmitarbeiter müssen Kundenfragen gegen diese Dokumente beantworten, ohne sie alle zu lesen. Ich will einen Chat-Endpunkt, der eine Frage annimmt und eine geerdete Antwort mit Quellenangaben liefert.

Trigger: Webhook-Node. Das Frontend POSTet {question, user_id} auf die Webhook-URL.

Node-Graph:

Webhook > Frage embedden (Voyage- oder OpenAI-Embed-Node)
 > Qdrant-Search (Top 5, Score-Threshold 0,7)
 > Code (Kontext mit [1], [2]-Markern und Quelldateinamen formatieren)
 > Claude (Sonnet 4.6) > Code (Zitat-URLs einsetzen)
 > Respond to Webhook

Indexierung ist ein separater Workflow. Ich indexiere nicht on-the-fly. Ein zweiter n8n-Workflow läuft auf Schedule, durchläuft den Dokumenten-Ordner, chunked PDFs (512 Tokens mit 50 Overlap), embeddet und upserted nach Qdrant. Einmal indexieren, viele Male abfragen.

Claude-Prompt. Der Trick ist, das Modell zu zwingen, ausschließlich den geholten Kontext zu nutzen. Mein System-Block:

Beantworte Fragen AUSSCHLIESSLICH mit dem bereitgestellten Kontext. Jede Faktenaussage muss einen Quell-Marker wie [1] oder [3] referenzieren. Wenn der Kontext die Antwort nicht enthält, sage "Das konnte ich in den vorgelegten Dokumenten nicht finden" und stoppe. Nutze kein Außenwissen.

User-Message-Template:

Kontext:
[1] {chunks[0].text} (Quelle: {chunks[0].source})
[2] {chunks[1].text} (Quelle: {chunks[1].source})
...

Frage: {question}

Stolpersteine.

• Score-Threshold ist entscheidend. Unter 0,7 auf Voyage-Embeddings bekomme ich Müll-Kontext und das Modell halluziniert trotzdem. Threshold gegen einen gelabelten Set testen, bevor Sie liveschalten.
• Chunk-Overlap ist nicht optional. Ohne Overlap scheitern Antworten, die über Absatzgrenzen laufen.
• System-Prompt cachen. cache_control: {"type": "ephemeral"} auf den System-Block setzen. Auf einem Bot mit Traffic senkt das die Input-Kosten pro Cache-Hit um 90 Prozent.
• Niemals den User direkt in den Kontext-Block injizieren lassen. Sanitisieren.

Kosten. Sonnet 4.6 bei ~1500 Tokens Input (System + 5 Chunks + Frage), ~300 Tokens Output. Rund 0,009 $ pro Frage. Bei 1000 Queries pro Tag: 9 $. Cache-Hits drücken das auf etwa 3 $.

Eine Tiefenbehandlung der vollständigen RAG-Stack-Architektur folgt im RAG-Pipeline-Tutorial.

3. Geplante Content-Generierungs-Pipeline

Problem: Jeden Montagmorgen will ich einen Wochenbericht in Inbox und Slack: Umsatz, Kennzahlen, nennenswerte Ereignisse. Manuelle Aufbereitung kostete mich 40 Minuten pro Montag.

Trigger: Schedule-Node, jeden Montag 08:00 Europe/Berlin.

Node-Graph:

Schedule > HTTP Request (GA4 Data API, letzte 7 Tage)
         > HTTP Request (Stripe, Zahlungen letzte 7 Tage)
         > HTTP Request (Plausible, Pageviews)
 > Merge (drei JSON-Blobs zusammenführen)
 > Code (Top-10-Metriken mit Deltas vs. Vorwoche flach machen)
 > Claude (Sonnet 4.6, Tool Use für strukturierten Report)
 > Split in Batches
   > Slack Post Message (#weekly-report)
   > Gmail Send (Stakeholder-Liste)
   > Notion Create Page (Archiv)

Prompt-Design. Der häufige Fehler: rohes JSON ins Modell kippen. Nicht tun. Vorher in einem Code-Node zu einem kompakten Markdown-Briefing vorverdauen. Dann schreibt das Modell Narrativ aus sauberem Input.

System-Prompt für diesen Fall:

Du schreibst Wochenberichte für eine SaaS-Gründerin. Beginne mit dem, was sich gegenüber der Vorwoche geändert hat. Nutze absolute Zahlen, nicht nur Prozentwerte. Kein Füllmaterial. Keine "wir haben gesehen"- oder "wir haben beobachtet"-Eröffnungen. Ist eine Kennzahl flat, sage es in einer Zeile und mach weiter.

Tool-Schema gibt {headline, kpi_table, highlights, risks, next_week_focus} zurück. Das Tool-Output rendere ich in einem Code-Node nach Markdown, bevor es gepostet wird.

Stolpersteine.

• Zeitzone. Schedule-Node nutzt die n8n-Server-Zeitzone. Setzen Sie sie explizit, sonst ist Ihr Montag 08:00 jemand anderes Sonntag 22:00.
• GA4-Quota. Die API throttelt. Bauen Sie einen 2-Sekunden-Wait vor jeden Call, wenn Sie mehrere Reports nacheinander fahren.
• Slack-Message-Limit liegt bei 40.000 Zeichen. Notion-Block-Größe bei 2000 Zeichen pro Paragraph-Block. Splitten Sie entsprechend.

Kosten. Sonnet 4.6 bei ~800 Tokens Input und ~500 Tokens Output. Rund 0,008 $ pro Report. Einmal die Woche, also 0,40 $ im Jahr. Der Wert sind die 40 Minuten pro Woche, die ich zurückbekomme.

4. Kunden-Support-Auto-Antwort mit Freigabe

Problem: Ein Kunde betreibt einen SaaS-Helpdesk. Viele Tickets sind wiederkehrende Fragen mit bekannten Antworten. Sie wollen, dass KI Antworten entwirft, aber ein Mensch muss vor Versand freigeben.

Das ist das Human-in-the-Loop-Pattern. Der Schlüssel ist der Telegram-Node als Approval-Gate.

Trigger: Webhook aus dem Support-Formular.

Node-Graph:

Webhook > Code (Ticket-Payload normalisieren)
 > Claude (Haiku, Dringlichkeit + Kategorie klassifizieren)
 > IF (urgency == "high")
   YES: Slack Page an On-Call, Workflow stoppen
   NO:  Claude (Sonnet, Antwort-Entwurf via Tool Use)
        > Telegram Send Message (Entwurf + Annehmen/Bearbeiten/Ablehnen-Buttons)
        > Wait for Webhook (Approval-Callback)
        > Switch auf Approval-Entscheidung
          > [angenommen]   Gmail Send
          > [bearbeitet]   Gmail Send mit Edited Text
          > [abgelehnt]    TickTick Create Task (an Mensch eskalieren)

Der Telegram-Approval-Trick. Ich schicke den Entwurf mit Inline-Buttons. Jeder Button hittet eine Callback-URL — ein weiterer n8n-Webhook. Der Workflow setzt am Wait-for-Webhook-Node mit dem resumeUrl-Pattern fort.

Das Telegram-Bot-Pattern habe ich in Telegram-Bot mit Claude API bauen ausführlich beschrieben. Gleiche Architektur. Das Approval-Gate ist nur eine Telegram-Message mit Callback-Buttons.

Prompt für Antwort-Generierung.

Du entwirfst E-Mail-Antworten auf Kunden-Support-Tickets. Übernimm den Tonfall des Kunden (formal oder locker). Versprich nie Refunds, Timelines oder Kompensation. Wenn das Issue Engineering-Input erfordert, schreibe eine Holding-Reply, die das Ticket bestätigt und ankündigt, dass ein Team-Mitglied innerhalb von 24h zurückkommt.

Tool-Schema: {draft_reply, confidence, flags}, wobei flags ein Array ist mit Dingen wie refund_request oder legal_mention, die unabhängig vom Confidence-Score auf einen Menschen routen.

Stolpersteine.

• Wait-for-Webhook-Workflows bleiben resident. Wenn Ihr n8n Queue-Mode hat und eine 10-Minuten-Execution-Timeout, setzen Sie das Wait-Node-Timeout explizit, sonst verlieren Sie Runs.
• Senden Sie nie ohne menschliches Gate, bevor Sie nicht mindestens 200 freigegebene Entwürfe geloggt und die Edit-Rate gemessen haben. Liegt die Edit-Rate über 20 Prozent, ist der Prompt nicht reif.
• Loggen Sie die Approver-Entscheidung nach Postgres. Das ist Ihr Trainingssignal zum Verbessern des Prompts.

Kosten. Haiku-Klassifikation (~0,0002 $) plus Sonnet-Entwurf (~0,01 $). 0,01 $ pro Ticket. Bei 500 Tickets im Monat: 5 $. Eingesparte Arbeit: rund 10 Stunden.

5. Rechnungsverarbeitung und Kategorisierung

Problem: Lieferanten-Rechnungen kommen als PDF-Anhänge per E-Mail. Ich will sie strukturiert nach Airtable bringen — mit Vendor, Betrag, Datum, Währung und Kategorie — bereit für Abstimmung.

Trigger: Gmail mit Anhangsfilter (has:attachment filename:pdf).

Node-Graph:

Gmail Trigger > IF (Anhang ist PDF)
 > Extract from File (eingebauter PDF-Text-Node)
 > Claude (Sonnet 4.6, Tool Use für Extraktion)
 > IF (confidence < 0,8)
   YES: TickTick Create Task (Manuelle Prüfung) + Telegram-Notify
   NO:  Airtable Append Record
        > Slack Post Message (#bookkeeping, Summary-Zeile)
 > Gmail Add Label "verarbeitet"

Das Extraction-Tool.

{
  "name": "extract_invoice",
  "description": "Strukturierte Felder aus dem Text einer Rechnung extrahieren",
  "input_schema": {
    "type": "object",
    "properties": {
      "vendor_name": {"type": "string"},
      "invoice_number": {"type": "string"},
      "issue_date": {"type": "string", "format": "date"},
      "due_date": {"type": "string", "format": "date"},
      "amount_total": {"type": "number"},
      "amount_tax": {"type": "number"},
      "currency": {"type": "string", "enum": ["EUR", "USD", "GBP", "CHF"]},
      "category": {"type": "string", "enum": ["hosting", "software", "contractor", "travel", "office", "other"]},
      "confidence": {"type": "number", "minimum": 0, "maximum": 1},
      "notes": {"type": "string"}
    },
    "required": ["vendor_name", "amount_total", "currency", "confidence"]
  }
}

System-Prompt erzwingt konservative Extraktion:

Extrahiere die Felder aus dem Text. Ist ein Feld fehlend oder mehrdeutig, lass es leer und senke die Confidence. Rate niemals den Betrag. Schließe niemals aus dem Vendor-Namen allein auf die Währung. Ist der PDF-Text klar verstümmelt (OCR-Fehler), setze Confidence auf 0 und erkläre in `notes`.

Stolpersteine.

• Der eingebaute PDF-Text-Extraktor in n8n funktioniert auf Text-PDFs. Eingescannte Rechnungen (Image-PDFs) brauchen vorher OCR. Ich nutze einen Tesseract-Container über HTTP Request, wenn nötig. Budget einplanen, falls Ihre Vendoren image-lastig sind.
• Immer confidence ins Tool-Schema und Niedrig-Confidence-Runs auf manuelle Prüfung routen. Sonst landen schlechte Extraktionen still in Airtable und vergiften die Buchhaltung.
• Das currency-Enum verhindert, dass das Modell “EURO” oder “USDollar” erfindet. Enums sind die billigste Validierung der Welt.
• USt-Sätze unterscheiden sich pro Land (DE 19/7 %, AT 20/10 %, CH 8,1 %). Wenn Sie deterministische USt-Berechnung brauchen, machen Sie sie in einem Code-Node nach der Extraktion, nicht im Prompt.

Kosten. Sonnet 4.6 bei ~1200 Tokens Input (Rechnungstext) und ~200 Tokens Output. Rund 0,006 $ pro Rechnung. Bei 100 Rechnungen pro Monat: 0,60 $. Manuelle Erfassung waren 90 Sekunden pro Rechnung. Die KI braucht 8 Sekunden und wird um 16 Uhr nicht müde.

Gemeinsame Patterns über alle Workflows

Haiku zum Routen, Sonnet zum Generieren. Jeder Workflow oben folgt dem Prinzip. Der 10×-Kostenunterschied zählt im Volumen. Haiku 4.5 macht Klassifikation, Intent-Detection, Urgency-Scoring. Sonnet 4.6 macht Drafting, Summarization, Extraktion.

Strukturierter Output via Tool Use. Ich frage Claude nie nach “JSON only” im Prompt. Ich gebe ein Tool, erzwinge Tool-Choice, parse den Tool-Input. Mein Claude API Tool Use Guide deckt das Pattern in der Tiefe ab.

Immer Error-Branch auf Telegram. Jeder n8n-Node hat einen “On Error”-Output. Auf eine Telegram-Message verkabeln. Wenn etwas in der Produktion bricht, hören Sie davon in 30 Sekunden, nicht erst, wenn ein Kunde fragt, wo sein Report bleibt.

Token-Verbrauch nach Postgres loggen. Ein abschließender Code-Node schreibt {workflow_id, run_id, model, input_tokens, output_tokens, cost_usd, timestamp} in eine llm_usage-Tabelle. Wöchentliche Rollup-Queries fangen den Moment, in dem ein Prompt unbeabsichtigt länger wurde und die Monatsrechnung sich verdoppelt hat.

Rate-Limits respektieren. Wenn Claude rate-limitet, hat der Fehler einen retry-after-Header. n8n-Wait-Node im Error-Branch nutzen, ihn respektieren. Nicht hämmern.

Aggressiv cachen. Bei jedem Workflow mit stabilem System-Prompt: cache_control: {"type": "ephemeral"} auf den System-Block. Cache-Hits kosten 10 Prozent eines Cold-Reads. Details im Prompt-Caching-Beitrag.

Prompts versionieren. Prompt-Text in einen Set-Node oder eine in Git committed JSON-Datei. Nicht live im Claude-Node editieren. Sie wollen einen Diff-Trail.

Wann Sie n8n nicht für KI nutzen sollten

Ich liefere auch viele Code-Agenten aus. Hier überspringe ich n8n und gehe direkt in Code:

Ultra-Low-Latency-Chat-UIs. Jeder n8n-Webhook addiert 100 bis 300 ms Overhead. Für ein User-facing Chat, in dem Latenz zählt, schreibe ich den Agent in Node, Go oder Python und streame Tokens direkt an den Client. Webhooks brechen Streaming.

Agent-Loops mit mehr als fünf Tool-Calls pro Turn. n8n kann Agent-Loops via LangChain-Agent-Node, aber Debugging wird schwer, wenn der Loop 20 Iterationen hat. In Code ist eine while-Loop mit strukturiertem Logging klarer.

Schwere Datei-Verarbeitung. Wenn Sie 500-MB-CSVs streamen oder Terabytes an Video chunken, machen Sie das in einem Skript mit echtem Streaming. n8n lädt Items pro Execution in den Speicher. Sie OOMen.

Echtzeit-Event-Verarbeitung at scale. Kafka-Consumer, Hochdurchsatz-Webhook-Fanouts, alles über ~50 Events pro Sekunde. n8n-Queue-Mode hilft, aber dedizierte Infrastruktur ist günstiger und schneller.

CLI-first Workflows. Wenn der Trigger “ein Entwickler ruft ein Kommando auf” ist, überspringen Sie n8n und schreiben ein CLI.

Für alles andere liefert n8n schneller und ist leichter zu übergeben.

Diese Workflows auf self-hosted n8n deployen

Alle fünf Workflows laufen auf einer self-hosted n8n-Instanz auf einem Hetzner-VPS. Managed Cloud funktioniert auch, aber Self-Hosting gibt Ihnen unbegrenzte Executions zu Flat-Cost — was zählt, sobald Sie ungefähr 500 Runs pro Tag erreichen. Mein n8n-selbst-hosten-Guide führt durch das Docker-Compose-Setup, Postgres, Redis für Queue-Mode und den Reverse Proxy.

DSGVO-Vorteil obendrein: alle Customer-Daten, API-Keys und Webhook-Payloads bleiben auf Ihrem EU-Server. Kein Auftragsverarbeitungsvertrag mit einem US-SaaS-Anbieter. Kein Schrems-II-Diskurs mit dem Datenschutzbeauftragten.

Die Workflow-JSON-Exports sind über n8n-Versionen hinweg stabil. Importieren, Credentials wiren (Claude API Key, Gmail OAuth, Qdrant URL), und sie laufen.

Wenn Sie diesen Stack für Ihr Unternehmen aufbauen lassen wollen, statt selbst zu wiren: ich zeige in einer Stunde mit einem erfahrenen KI-Berater konkret, was sich für Ihren Use Case rechnet, oder Sie buchen einen externen KI-Engineer tageweise für die Umsetzung.

Weiterführende Artikel

• Make.com vs. n8n für Produktivlasten
• n8n selbst hosten: Docker, Postgres, DSGVO-konform
• Claude API Tool Use
• Telegram-Bot mit Claude API bauen
• KI-Berater finden