n8n Agents: Wann ein Agent die richtige Antwort ist — und wann ein stumpfer Workflow besser bleibt

Das Problem

n8n hat am 25. September Agents vorgestellt, und die erste Reaktion war absehbar: Was können wir jetzt damit machen? Das ist die falsche Frage. Die richtige ist dieselbe wie bei jeder Automatisierung: Soll ich das überhaupt — und rechnet es sich?

Ich habe im April eine Regel dafür aufgeschrieben, und sie gilt unverändert. Was sich geändert hat, ist die Kostenseite. Ein Agent bringt eine Position mit, die ein Workflow nicht hat: Er kann falsch liegen, ohne dass es auffällt. Das kostet Prüfzeit, und Prüfzeit ist eine laufende Kostenposition — keine Kinderkrankheit, die sich nach drei Wochen erledigt.

Dieser Beitrag beantwortet zwei Fragen: Wann ist ein Agent tatsächlich die bessere Lösung, und wann bleibt der stumpfe, langweilige Workflow überlegen? Plus: was Agents kosten, und was self-hosted derzeit noch nicht geht.

Was n8n am 25. September vorgestellt hat

In der Ankündigung steht der entscheidende Satz nicht im Marketing-Teil, sondern in der Abgrenzung:

„Sometimes you want the workflow in charge, with the agent as a step inside it. Sometimes you want the agent in charge, with workflows as tools."

Damit ist klar, was Agents sind: kein Ersatz für Workflows, sondern ein zweiter Objekttyp daneben. Beide Richtungen sind vorgesehen — Agent als Schritt im Workflow, oder Workflow als Werkzeug des Agenten. Wer den Agenten als Nachfolger des Workflows liest, hat die Ankündigung falsch gelesen.

Für diesen Beitrag habe ich das auf einer eigenen Instanz aufgesetzt — Docker-Image 2.41.3, Agents-Modul aktiviert. So sieht es dort aus: Agents stehen als eigener Reiter neben den Workflows, mit Preview-Kennzeichnung.

Der Unterschied in der Sache:

Die letzte Zeile ist die wichtigste. Ein kaputter Workflow schreit. Ein Agent, der die falsche Bestellung erwischt, formuliert eine höfliche, gut lesbare, sachlich falsche Antwort.

Was laut Dokumentation bei jedem Agent dabei ist:

• Instructions — Rolle, Ton und Grenzen in natürlicher Sprache statt als Knoten-Graph.
• Tools — n8n-Integrationen, eigene Workflows, Code oder MCP-Server. Dazu „Skills": wiederverwendbare Bündel aus Anweisung und Werkzeugen.
• Sessions — jedes Gespräch wird gespeichert und ist einsehbar: Nachrichten, Tool-Aufrufe, offene und abgelehnte Freigaben als getrennte Ereignisse.
• Memory — Session-Memory für das laufende Gespräch ist Standard und lässt sich nicht abschalten. Die Memory über Sessions hinweg (in der Doku „episodic memory", in der Oberfläche Cross-session memory) ist optional und braucht ein OpenAI-Credential. Das ist eine Abhängigkeit, die man vor dem Pilotstart kennen sollte.
• Kanäle — Slack, Telegram, Linear, dazu geplante Ausführung.
• Draft und Published — am Draft wird gearbeitet, die veröffentlichte Version läuft in Produktion, frühere Versionen sind wiederherstellbar. Unpublish nimmt den Agent offline, ohne den Draft zu löschen. Das ist mehr Release-Disziplin als der Workflow-Editor bisher hergibt.
• Sub-Agents — ein Agent kann an einen anderen delegieren, aber nur an einen veröffentlichten.
• Knowledge Base — CSV, PDF, Markdown und TXT als Grundlage für Antworten; Vector Stores werden unterstützt.
• Approvals — als sensibel markierte Werkzeuge pausieren und fragen nach, bevor sie laufen.

Und der Rahmen, in dem das alles steht, ebenfalls aus der Doku:

„Agents are in Preview. They can make mistakes, and their behavior may change while the feature is in development."

Das ist keine Floskel. Dazu später bei den Kosten mehr.

Der eine Satz, auf den es ankommt

Aus der Ankündigung:

„Each tool runs with the credential you attached to it. The agent never holds the keys to your instance."

Das ist die wichtigste Zeile der ganzen Vorstellung, und sie wird unterschätzt. Das Sicherheitsmodell eines Agenten ist nicht das Modell. Es ist der Zuschnitt seiner Werkzeuge.

Ein Werkzeug, das eine Bestellnummer annimmt und Status, Zahlart und Sendungsnummer zurückgibt, ist sicher — vollkommen unabhängig davon, wie kreativ das Modell an einem schlechten Tag wird. Es kann nichts anderes tun. Ein Werkzeug namens „Admin API" mit einem Credential, das alles darf, ist es nie. Kein Prompt, keine Anweisung und kein Modellwechsel macht daraus eine Absicherung.

Praktisch heißt das: Die Arbeit an einem Agenten ist zu achtzig Prozent Werkzeugdesign und zu zwanzig Prozent Instructions. Wer bei den Instructions anfängt, baut es zweimal.

Der Vorteil, der zwischen den Feature-Listen untergeht

Bis vor Kurzem sah der Weg zum eigenen Agenten so aus: Man stellt ein Agenten-Framework neben die Automatisierung. OpenClaw und Hermes Agent sind die bekanntesten, beide self-hosted, beide gut in dem, was sie tun — eigenes Modell, eigenes Gedächtnis, Gateways in jeden Messenger.

Für einen Shop ist das aber ein zweites System. Zweite Installation, zweiter Credential-Speicher, zweite Update-Kette, zweite Stelle, an der um drei Uhr nachts etwas klemmt. Und die halbe Arbeit macht man doppelt, weil die Anbindungen an Shop, ERP und Mailserver in n8n längst stehen.

Genau da liegt der Punkt, der in der Ankündigung zwischen den Feature-Listen untergeht — und er ist für die Praxis wichtiger als jedes einzelne Feature.

Alles aus einer Hand. Für die meisten Fälle im Shop-Betrieb braucht es kein zusätzliches Framework mehr. Ein System, eine Rechteverwaltung, ein Ort für Logs, ein Update-Zyklus. Das ist kein Argument über Funktionsumfang, sondern über Betriebskosten — und genau die werden bei Automatisierungsprojekten regelmäßig unterschätzt. Ehrlich bleiben muss man trotzdem: Wer einen persönlichen Assistenten auf eigener Hardware will, der Dateien sortiert und über sechzehn Messenger erreichbar ist, ist mit den Frameworks weiterhin besser bedient. Für Prozesse, die ohnehin an deinen Systemen hängen, nicht.

Die Schnittstellen sind schon angebunden. Das ist der größte praktische Hebel. Der Aufwand an einem Agenten steckt nie im Modell, sondern in den Anbindungen. n8n bringt mehrere hundert Integrationen mit, und wer die Instanz schon betreibt, hat die relevanten davon bereits verbunden — mit Credentials, die funktionieren und im Alltag getestet sind.

In der Werkzeugauswahl des Agenten sieht man das direkt: Ganz oben stehen die eigenen Workflows als „Connected", darunter 77 MCP-Server und über 99 n8n-Nodes. Man sucht sich das Werkzeug aus einem Bestand aus, statt es zu bauen.

Dazu kommt etwas, das direkt am Abschnitt oben hängt: Ein bestehender Workflow ist bereits schmal geschnitten. Er hat definierte Eingaben, definierte Ausgaben und ein Credential, das genau so viel darf, wie er braucht. Damit ist er ohne Umbau ein brauchbares Agenten-Werkzeug. Das ist der Unterschied zwischen zwei Wochen Prototyp und zwei Tagen.

Du kannst wechseln, statt dich einmalig zu entscheiden. Der Satz aus der Ankündigung — Workflow in charge oder Agent in charge — ist keine Marketing-Symmetrie, sondern die praktische Folge davon, dass beides im selben System lebt. Derselbe Prozess kann den deterministischen Teil als Workflow behalten und nur den unklaren Teil an einen Agenten geben: Der Agent klassifiziert, alles danach ist fest verdrahtet. Oder andersherum. Und wenn sich herausstellt, dass der Agent an dieser Stelle nichts bringt, baust du ihn zurück, ohne die Anbindungen neu zu bauen — die Werkzeuge bleiben dieselben.

Das entschärft die Entscheidung, um die es in diesem Beitrag geht. Es hebt sie nicht auf.

Wann ein Agent die richtige Antwort ist

Die Doku formuliert das Kriterium als Arbeit, die „too open-ended for a fixed workflow" ist. Konkreter, aus der Praxis — ein Agent lohnt sich, wenn mehrere dieser Punkte zutreffen:

• Der Eingang ist natürliche Sprache. Eine Kundenmail, eine Chat-Nachricht, ein Ticket-Text. Etwas, das du nicht in ein Feld-Mapping überführen kannst, ohne die Hälfte zu verlieren.
• Die Reihenfolge der Schritte hängt vom Inhalt ab. Bei „Wo ist meine Bestellung?" wird nachgesehen. Bei „Das Teil ist kaputt" wird etwas ganz anderes gemacht. Ein Workflow bräuchte hier einen Verzweigungsbaum, den niemand pflegen will.
• Die Varianz ist hoch, die Frequenz überschaubar. Zwanzig unterschiedliche Fälle am Tag sind ein Agenten-Fall. Zwanzigtausend gleichförmige Fälle am Tag sind es nicht — da wird jede Runde zur Kostenposition.
• Ein Mensch würde an dieser Stelle nachfragen. Genau dafür sind Sessions und Approvals gebaut. Wenn der Prozess eine Rückfrage verträgt, verträgt er einen Agenten.

Wann der stumpfe Workflow besser bleibt

Die Gegenliste ist länger, und das ist Absicht:

• Der Auslöser ist technisch eindeutig. Statuswechsel, Cron, Webhook. Wenn du den Auslöser als Ereignisnamen schreiben kannst, brauchst du niemanden, der ihn interpretiert.
• Die Schritte sind jedes Mal dieselben. Dann ist jede Modellrunde bezahlte Entscheidungsfindung über eine Frage, die längst entschieden ist.
• Das Ergebnis muss reproduzierbar sein. Buchhaltung, Steuer, Compliance, alles mit Meldepflicht. „Kann variieren" ist hier ein Ausschlusskriterium, kein Feature.
• Die Frequenz ist hoch. Siehe Kostenteil: eine Agent-Runde ist eine Execution, und ein Agent dreht selten nur eine Runde.
• Fehler sind teuer und von außen nicht erkennbar. Der Workflow bricht ab und meldet sich. Der Agent liefert weiter.

Das Musterbeispiel dafür ist die Zahlungserinnerung bei fehlgeschlagener Zahlung, die ich vor zwei Wochen beschrieben habe. Der Auslöser ist fest, die Schritte sind fest, und der Schutz gegen Doppel-Mails ist ein Merker, der gesetzt ist oder nicht. Da gibt es nichts zu entscheiden. Ein Agent wäre dort teurer, langsamer und in einem Punkt echt schlechter: Ein Merker, den ein Modell „berücksichtigt", ist kein Merker.

Anders gesagt: Ein Agent ist kein besserer Workflow. Er ist eine andere Sorte Werkzeug für eine andere Sorte Problem.

Die 12-Monats-Regel bekommt eine neue Zeile

Meine 12-Monats-Regel sagt: Eine Automatisierung muss sich in unter zwölf Monaten amortisieren, weil nach einem Jahr Schnittstellen, Updates und Prozesse so weit gedriftet sind, dass die Wartung die Rechnung kippt. Diese Regel gilt für Agents genauso. Nur ist ihre Kostenseite unübersichtlicher.

Erstens die Ausführungskosten. n8n zählt eine Agent-Runde als eine Execution. Aufrufe angehängter Workflows und Sub-Agents zählen nicht zusätzlich, und Agents nutzen dasselbe Execution-Kontingent wie Workflows. Das klingt günstig — bis man den Multiplikator sieht: Ein Agent, der für einen Fall vier Runden dreht, verbraucht vier Executions statt einer. Bei einem Workflow ist ein Fall ein Lauf. Bei einem Agenten ist ein Fall so viele Läufe, wie das Modell für nötig hält.

Zweitens die Modellkosten. Die laufen getrennt, über das eigene Credential oder über Gateway-Credits. Sie stehen in keiner Execution-Statistik und sind die Position, die in Schätzungen regelmäßig fehlt.

Drittens der Korrekturaufwand. Das ist die neue Zeile. Jede falsche Antwort kostet die Zeit, sie zu finden, plus die Zeit, sie zu beheben, plus gelegentlich Kundenvertrauen. Die Session-Ansicht hilft beim Finden, sie ersetzt aber niemanden, der hinsieht. Wer einen Agenten auf Kundenkontakt lässt, kalkuliert diese Prüfzeit als dauerhafte Position ein, nicht als Anlauf.

Viertens der Preview-Status als Wartungsposition. „Their behavior may change while the feature is in development" ist eine Ankündigung, kein Haftungsausschluss. Ein Agent, der heute sauber läuft, kann nach einem Update anders entscheiden. Bei einem Workflow ist das ein Bug. Hier ist es eingeplant.

Zusammengerechnet: Die manuelle Seite der Rechnung bleibt, wie sie war. Die Automatisierungsseite ist unsicherer geworden. Daraus folgt nicht, dass die Regel gelockert wird, weil das Werkzeug neu und spannend ist. Es folgt das Gegenteil: Bei einem Agenten braucht die Rechnung mehr Luft, nicht weniger. Wenn sie nur mit optimistischen Annahmen aufgeht, geht sie nicht auf.

Den manuellen Teil kannst du hier ausrechnen. Die Agenten-Seite — Executions mal Runden, Modellkosten, Prüfzeit — kommt von Hand dazu:

Das Beispiel: Kundenanfragen im Shop

Der Fall, bei dem sich das für einen Shop am ehesten rechnet, ist der Eingang: Kundenanfragen kommen als Text, in beliebiger Formulierung, zu einem von etwa acht Themen. Klassischer Agenten-Fall — hohe Varianz, natürliche Sprache, eine Rückfrage ist zumutbar.

Der Zuschnitt, den ich dafür bauen würde: Der Agent klassifiziert die Anfrage, holt sich über ein schmales Lese-Werkzeug an der Shopware-Admin-API die Bestelldaten dazu — Status, Zahlart, Sendungsnummer, nicht mehr — und formuliert einen Antwortentwurf. Der Entwurf geht an einen Menschen, nicht an den Kunden. Alles mit Geldbezug, also Gutschrift, Storno und Erstattung, hängt an einem eigenen Werkzeug mit Approval-Gate: Der Agent darf es vorschlagen, auslösen darf es nur jemand mit Klick.

In vielen Shops existieren zwei dieser Werkzeuge bereits — als Workflow, gebaut für einen ganz anderen Zweck. Die Bestellabfrage, die heute ein Reporting füttert, ist morgen das Lese-Werkzeug des Agenten. Das ist der Teil, der die Rechnung kippen kann: Man baut keinen Agenten von null, man hängt ihn an Vorhandenes.

Zwei Dinge daran entscheiden über Erfolg oder Ärger:

Das Credential am Lese-Werkzeug darf nur lesen. Die Integration dahinter bekommt order:read — nicht order:update. Wie so eine Integration aufgesetzt wird und warum es ein Integrations-Zugang und kein Admin-Benutzer sein sollte, steht im Zahlungserinnerungs-Beitrag ausführlich. Wenn das Werkzeug nicht schreiben kann, ist die schlimmste Folge einer Fehlentscheidung eine falsche Auskunft — nicht ein falscher Datenstand.

So sieht der Agent dann aus. Unter Capabilities hängen die beiden Workflows als Werkzeuge, die Instructions stehen darüber in einem Absatz Klartext:

Und das Approval-Gate ist genau ein Schalter am Werkzeug — nicht etwas, das man sich im Prompt zusammenformuliert:

Der Hinweis unter dem Beschreibungsfeld ist übrigens die ganze Wahrheit über Agenten-Werkzeuge: The LLM reads this to decide when to call the workflow. Die Beschreibung ist kein Kommentar, sie ist Steuerung.

Der Agent verschickt nichts selbst. Das ist die Grenze, die ich in einem Pilot nicht verschiebe. Nicht weil das Modell zu schlecht wäre, sondern weil eine rausgeschickte Mail nicht zurückkommt. Wenn nach drei Monaten die Session-Historie zeigt, dass die Entwürfe in einer bestimmten Kategorie praktisch immer unverändert durchgehen, kann man diese Kategorie freigeben. Das ist eine Entscheidung mit Daten, keine mit Bauchgefühl.

Was hier bewusst kein Agent macht: die Bestandsbuchung, die Rechnungsstellung, den Statuswechsel. Das sind feste Abläufe. Die bleiben Workflow.

Self-hosted: geht, aber mit Sternchen

Agents sind in der Cloud sofort verfügbar. Self-hosted gehen sie auch, aber die Einschränkungen sind der eigentliche Teil der Nachricht. Laut Doku: „Agents run on self-hosted n8n from 2.32.3." Das Modul muss über N8N_ENABLED_MODULES aktiviert werden, Kanäle brauchen eine öffentlich erreichbare WEBHOOK_URL, und die Knowledge Base setzt eine Daytona-Sandbox voraus — also eine zusätzliche Komponente neben n8n selbst.

Der Satz, der davon am meisten weh tut, steht ebenfalls dort:

„Queue mode isn't supported for agents yet, and connecting channels (such as Telegram) can fail."

Wer n8n im Queue Mode betreibt — also alle, die skaliert oder halbwegs ausfallsicher fahren —, kann Agents derzeit nicht einfach dazuschalten. Das ist kein Detail in einer Fußnote, das ist eine Architekturfrage. Dazu kommt: Für self-hosted Enterprise fehlt die Unterstützung noch ganz.

Was davon in der Praxis trägt: Die Oberfläche in diesem Beitrag läuft auf genau so einer Instanz — Standard-Image, Agents-Modul an, sonst nichts. Bauen, Werkzeuge anhängen und Freigaben konfigurieren geht damit vollständig. Was ohne Modell-Credential nicht geht, ist der Agent selbst: Ohne hinterlegtes Modell lässt er sich nicht veröffentlichen, und ohne Veröffentlichung gibt es keine Sessions.

Meine Empfehlung für den Moment ist deshalb unspektakulär: Pilot in der Cloud, Entscheidung über Self-Hosting später. Ein Agent im Preview-Status auf einer Produktions-Instanz umzubauen, deren Betriebsmodell er noch nicht unterstützt, ist Aufwand an der falschen Stelle. Wenn der Pilot zeigt, dass sich der Fall rechnet, ist die Self-Hosting-Frage in ein paar Releases ohnehin eine andere.

Fazit

Agents sind ein echtes neues Werkzeug — und kein neues Argument. Die Frage bleibt, ob ein Prozess sich in unter zwölf Monaten rechnet. Neu ist nur, dass bei einem Agenten mehr Unsicherheit in dieser Rechnung steckt: Runden statt Läufe, Modellkosten neben Executions, Prüfzeit als Dauerposten, Verhaltensänderungen als eingeplantes Risiko.

Der Plattformvorteil ist dabei real und wird unterschätzt: Wer n8n ohnehin betreibt, kommt ohne zweites System und mit fertigen Anbindungen zum Agenten, und kann zwischen deterministisch und dynamisch hin und her wechseln, statt sich einmal festzulegen. Das senkt die Einstiegskosten deutlich. Es senkt nicht den Korrekturaufwand. Die Rechnung bleibt dieselbe — sie fängt nur weiter vorne an.

Die drei Sätze, die ich mir aus der Vorstellung mitnehme:

1. Der Tool-Zuschnitt ist das Sicherheitsmodell. Das Credential hängt am Werkzeug, nicht am Agenten — also entscheidet die Schnittstelle des Werkzeugs, was im schlimmsten Fall passieren kann.
2. Unstrukturierter Eingang ist das Kriterium. Nicht „KI wäre hier auch nett", sondern: Kann ich die Schritte vorher festlegen? Wenn ja, ist es ein Workflow.
3. Alles mit Geldbezug gehört ins Approval-Gate. Dauerhaft, nicht nur in der Pilotphase.

Wenn du überlegst, ob einer deiner Prozesse ein Agenten-Fall ist: Die Vorgehensweise ist dieselbe wie immer — erst rechnen, dann bauen. Und wenn du wissen willst, ob es sich in deinem Fall lohnt, sage ich dir das ehrlich, auch wenn die Antwort „lass es" ist. Meld dich.

Quellen

• n8n Blog: Introducing n8n Agents (abgerufen am 29.09.2026)
• n8n Docs: Build and manage agents (abgerufen am 29.09.2026)
• n8n Docs: Release notes — um die Mindestversion gegen die eigene Installation zu prüfen
• n8n Docs: Integrations — Übersicht der verfügbaren Nodes

Agents sind zum Zeitpunkt dieses Beitrags als Preview gekennzeichnet. Einzelne Angaben können sich mit den nächsten Releases ändern.