n8n verdrahten kann jeder. Kaum jemand kann dir sagen, wo n8n aufhört. Genau diese Lücke ist die eigentliche Arbeit. Echte Automatisierung sind drei Schichten, nicht ein Tool, und die Schicht die die meisten bauen ist das einfache Drittel. Wir betreiben alle drei in Produktion, in unseren eigenen Systemen und für Kunden, und der Wert lag nie in dem Teil den jeder ohnehin schon hat.
n8n hatte ein seltsames Jahr. Im Oktober 2025 sammelte die Firma 180 Millionen Dollar ein und überschritt eine Bewertung von 2,5 Milliarden Dollar, von 300 Millionen vier Monate vorher. Rund 230.000 Leute betreiben es inzwischen, drei Viertel davon mit den AI Nodes. Jeder zweite Automatisierungs-Post auf LinkedIn ist ein n8n Canvas mit ein paar Kästchen und einem Pfeil. Das Tool hat den Hype verdient. Es ist wirklich gut, selbst hostbar, und es verbindet sich mit fast allem.
Und genau dort hören die meisten Automatisierungsprojekte still auf. Jemand setzt n8n auf, verdrahtet einen Webhook mit einer Slack-Nachricht, nennt das eine Automatisierungsstrategie und macht weiter. Es funktioniert, bis der Workflow eine Einschätzung treffen muss, oder bis er vier Tage und einen Server-Neustart überstehen muss, ohne den Faden zu verlieren. Dann ist das visuelle Canvas am Ende der Straße, und die Leute die nur das Canvas kennen, sind es mit ihm.
Was Automatisierung wirklich braucht
Nimm die Tools weg und es bleiben drei Aufgaben unter jeder ernsthaften Automatisierung. Es sind unterschiedliche Probleme, und ein Tool das eines gut löst, löst die anderen beiden meist schlecht.
Die erste Aufgabe ist Dinge verbinden. Ein Signup kommt rein, ein Datensatz landet im CRM, eine Willkommensmail geht raus, eine Benachrichtigung erscheint auf jemandes Handy. Kein Denken nötig, nur zuverlässige Verkabelung zwischen Systemen die nie dafür gebaut wurden, miteinander zu reden. Das ist der Großteil der Automatisierung nach Volumen, und es ist die Aufgabe für die n8n gebaut wurde.
Die zweite Aufgabe ist eine Einschätzung treffen. Der Workflow muss etwas Mehrdeutiges lesen, entscheiden was es bedeutet, und den nächsten Schritt anhand dieser Entscheidung wählen. Eine E-Mail kommt rein und das System muss beurteilen, ob es ein echter Lead ist oder Rauschen, und dann entsprechend routen. Ein Entwurf wird geprüft und das System muss entscheiden, ob er gut genug zum Ausspielen ist oder noch eine Runde braucht. Das ist keine Verkabelung. Das ist Reasoning, und es braucht eine andere Art von Tool.
Die dritte Aufgabe ist über Zeit überleben. Manche Workflows laufen Stunden oder Tage. Sie warten darauf, dass ein Mensch etwas freigibt. Sie rufen sechs externe Dienste auf, von denen jeder ausfallen kann, und ein Ausfall auf halbem Weg darf die anderen fünf nicht beschädigen. Wenn die Maschine bei Schritt vier von sieben neu startet, muss die Arbeit bei Schritt vier weitergehen, nicht von vorne beginnen. Das ist durable Execution, und sie ist von den dreien am schwersten vorzutäuschen.
Diese drei Aufgaben sind orthogonal. Ein Tool das versucht, alle drei gleichzeitig zu sein, wird in jedem mittelmäßig. Ein Stack der für jede Schicht den richtigen Spezialisten wählt, schlägt die Eier-legende Wollmilchsau jedes Mal. Unsere drei Spezialisten sind n8n, LangGraph und Temporal.
n8n: Die Schicht die jeder schon hat
n8n ist die verbindende Schicht, und für diese Aufgabe ist es ausgezeichnet. Über 400 vorgebaute Integrationen, ein visuelles Canvas das auch ein Nicht-Entwickler tatsächlich lesen kann, Self-Hosting in unter einer halben Stunde. Wir betreiben es als Automatisierungs-Hub für die unglamouröse Arbeit, die ein Geschäft am Laufen hält. Ein Signup-Webhook der einen CRM-Lead anlegt und eine Willkommensmail abfeuert. Ein neuer Blog-Post der sich in Social-Post-Entwürfe auffächert. Ein geplanter Health Check der eine Reihe von Diensten anpingt und einen Kanal alarmiert, wenn einer verstummt. Eine eingehende E-Mail die auf Absicht geparst wird, bevor sie einen Menschen erreicht.
Das ist echter Wert und das will ich klar sagen. n8n ist kein Spielzeug und kein Zapier für Power-User. Es ist eine richtige, fair lizenzierte, selbst hostbare Orchestrierungsplattform, und für das Verbinden von Systemen ist es oft die schnellste richtige Antwort. Wenn ein Kunde will, dass sein Ops-Team einen Workflow ohne Deployment-Zyklus bearbeiten kann, gewinnt das visuelle Canvas aus eigener Kraft.
Die Ehrlichkeit fängt an, wenn man anschaut, was n8n nicht ist. Es führt Schritte standardmäßig nacheinander aus, also wird echte parallele Arbeit mit geteiltem State schnell brüchig. Leute berichten von Merge Nodes die ein paar Prozent der Fälle an Race Conditions scheitern, die in kontrolliertem Code schlicht nicht existieren. Es ist keine State Machine mit deterministischem Replay, also setzt ein Crash mitten im Lauf nicht sauber fort. Es gibt kein erstklassiges Testing. Und in dem Moment, in dem ein Workflow irgendetwas Ungewöhnliches braucht, landet man in einer Code Node, und die Code Node ist der Ort, an dem n8n Workflows still die technischen Schulden ansammeln, die niemand aufs Canvas gemalt hat. Nichts davon ist ein Fehler. Es ist einfach der Rand der Schicht. Der Fehler ist nicht, n8n zu nutzen. Der Fehler ist zu glauben, das Canvas sei die ganze Karte.
LangGraph: Wenn der Workflow denken muss
Wenn ein Workflow nachdenken muss statt nur zu routen, greifen wir zu LangGraph. Es ist ein Code-first Framework vom LangChain-Team, das einen Workflow als Graph von Schritten modelliert, in dem das Sprachmodell, nicht ein festes Diagramm, entscheidet was als Nächstes passiert. Seit LangChain 1.0 ausgeliefert wurde, laufen LangChains eigene Agents darunter auf LangGraph, und die Liste der Produktiv-Nutzer liest sich wie ein Who's Who, mit Uber, LinkedIn, Klarna und Replit darauf.
Die zwei Features die ihm seinen Platz verdienen, sind State und Pausing. State heißt, der Workflow merkt sich, wo er steht. Jeder Schritt wird als Checkpoint in eine Datenbank geschrieben, also setzt ein Crash bei Schritt drei wieder bei Schritt drei an, statt den ganzen Lauf zu verbrennen. Pausing heißt, der Workflow kann mittendrin anhalten, darauf warten dass ein Mensch etwas freigibt oder korrigiert, und dann mit dieser Antwort weiterlaufen. In LangGraph ist das ein Primitiv, kein selbstgebautes Nebensystem.
Eine konkrete Form die wir darauf betreiben: eine Pipeline aus mehreren Agents, in der ein Schritt einen Plan entwirft, der nächste dagegen baut, ein dritter das Ergebnis prüft und ein vierter es testet, mit einem Approval Gate das die ganze Sache für einen Menschen pausiert, sobald die Prüfung unsicher zurückkommt. Das ist Reasoning plus Checkpoints plus Human in the Loop, genau die Kombination für die LangGraph existiert, und genau die Kombination die n8ns Canvas nur mühsam ausdrücken kann, mit verschachtelten Sub-Workflows und Polling-Tricks.
Der Trade-off ist real und gehört laut ausgesprochen. LangGraph ist Overkill für einen Workflow der nur ein Modell aufruft und das Ergebnis irgendwo postet. Greif zu früh dazu und du hast zweihundert Zeilen Framework-Code geschrieben, wo fünfzig Zeilen schlichte Logik klarer gelesen hätten. Es trägt außerdem eine proprietäre Lizenz, was ein Lock-in-Risiko ist, das wir bewusst steuern statt es zu ignorieren. Die Disziplin ist, es nur dort einzusetzen, wo Reasoning und Resume das zusätzliche Gewicht wirklich rechtfertigen.
Temporal: Wenn der Workflow nicht sterben darf
Die dritte Schicht ist die, von der in der n8n-Szene fast niemand je gehört hat, und sie ist die, die ein Hobby-Setup von Infrastruktur trennt. Temporal ist eine Durable Execution Engine. Sie zeichnet jeden Schritt eines Workflows als Event History auf, also fährt sie bei einem Server-Crash einen frischen Worker hoch, spielt die History bis zum exakten State vor dem Crash zurück und macht weiter, als wäre nichts gewesen. Workflows können Tage oder Jahre laufen. Es ist Open Source unter der MIT-Lizenz und hat sich still zum Standard für durable Agent-Ausführung entwickelt. OpenAI betreibt Codex damit in Produktion, für Agents die tagelang auf menschliche Freigabe warten und Neustarts überstehen, ohne den Faden zu verlieren.
Was das freischaltet, ist die Klasse von Workflows die die echte Welt berühren und es sich nicht leisten können, halb fertig zu sein. Ein Billing-Lebenszyklus, in dem ein Abo erneuert wird, eine Zahlung eingezogen wird und ein Refund eine Kette von Seiteneffekten sauber zurückrollen muss, wenn ein Schritt scheitert. Ein Customer Onboarding das über mehrere Tage läuft, mit eingebauten Timern und Wartezeiten. Ein wiederkehrender Job der Arbeit über viele Quellen aggregiert und jedes einzelne Mal zuverlässig durchlaufen muss. Das sind Sagas, langlaufende Transaktionen mit Kompensation wenn etwas bricht, und genau das war ein visuelles Canvas nie dafür gedacht zu halten.
Es gibt eine saubere Faustregel auf die sich das Feld geeinigt hat, und wir nutzen sie. Wenn eine Aufgabe ein einzelner, read-only Schritt unter 30 Sekunden ist, brauchst du nichts davon. In dem Moment, in dem ein Workflow drei oder mehr externe Aufrufe macht, stundenlang auf ein Event wartet, oder unumkehrbare Aktionen wie Zahlungen oder Löschungen auslöst, hört durable Execution auf optional zu sein. Wir veröffentlichen eine Sammlung durabler Workflow-Templates als Open Source, damit das Muster keine Blackbox ist, verfügbar unter github.com/studiomeyer-io/temporal-memory-workflows. Die Kosten von Temporal sind operativer Overhead und ein paar Regeln dafür wie du den Code schreibst, was genau der Grund ist, warum man unterhalb der Schwelle nicht dazu greift.
Wie die drei Schichten zusammenpassen
Die Falle ist zu fragen, welches Tool gewinnt. Keines gewinnt, weil sie nicht dasselbe Spiel spielen. n8n verbindet Systeme und löst Dinge aus. LangGraph denkt nach und pausiert für Menschen. Temporal garantiert, dass lange, wichtige Arbeit zu Ende kommt. In einem ausgereiften Setup stapeln sie sich: n8n fängt das Event ab und macht den Kleber, übergibt das Denken an einen LangGraph-Agent und umhüllt alles Langlaufende oder Unumkehrbare in einem Temporal-Workflow, sodass ein Crash ein Non-Event ist. Die Observability-Seite genau dieser Architektur, also zu beobachten was jede Schicht tatsächlich getan hat, ist eine eigene Disziplin die wir separat behandelt haben, in unserem Stück zum Agent Observability Stack.
Die mit Abstand wichtigste Gewohnheit über alle drei hinweg ist, deine eigentliche Business-Logik aus dem Framework herauszuhalten. Die Regeln deiner Domäne leben in schlichtem, getestetem Code den jedes dieser Tools bloß aufruft. Mach das und einen Workflow von einer Schicht in eine andere zu verschieben ist ein Tag Arbeit, kein Rewrite, weil der Teil der zählt nie vom Tool abhing. Lass es weg und du heiratest das Canvas mit dem du angefangen hast, und genau so landen Teams gefangen in einem n8n Workflow, der vor einem Jahr zu Code hätte aufsteigen sollen.
Das Setup ist Massenware. Die Architektur nicht.
Hier ist der Teil den der Markt verkehrt herum sieht. n8n aufzusetzen ist inzwischen Massenware. Es gibt tausende Leute die dir ein Canvas zeichnen, und der Preis dieser Arbeit fällt, weil das Tool es einfach gemacht hat, was der ganze Sinn war. Wenn alles was du kaufst das n8n-Setup ist, hast du die Schicht gekauft die ohnehin am billigsten zu bauen war.
Der Wert liegt in den zwei Entscheidungen die dir niemand verkauft. Erstens zu wissen, welche der drei Schichten ein gegebenes Problem wirklich braucht, und das Urteilsvermögen zu haben, beiden Fehlmodi zu widerstehen: ein Reasoning-Problem in eine n8n Code Node zu zwängen, bis es verrottet, und einen Fünfzig-Zeilen-Job zu einem durablen Workflow zu überkonstruieren den er nie brauchte. Zweitens die Grenze so sauber zu bauen, dass die Wahl billig zu revidieren bleibt. Das ist Architektur, und sie taucht auf einem Canvas-Screenshot nicht auf.
Es gibt noch eine Sache bei der Ehrlichkeit angebracht ist. Was unsere eigenen internen Systeme betreibt, ist bewusst pragmatisch, abgestimmt darauf gut genug für einen Solo-Betrieb zu sein, der seine eigenen Kanten kennt. Ein Kundenauftrag bekommt einen völlig anderen Gang, dieselben drei Schichten, aber mit der Härtung, den Governance-Gates vor riskanten Aktionen, der Observability und dem Testing das ein System auf das sich jemand anderes verlässt tatsächlich braucht. Den Unterschied zwischen gut-genug-für-uns und richtig-für-einen-Kunden zu kennen, ist selbst Teil davon, den Stack zu beherrschen. Die Tools betreiben kann jeder. Zu wissen wie weit man sie treibt, ist die Arbeit.
Wenn du also das nächste Mal ein Automatisierungs-Pitch siehst, das mit n8n anfängt und mit n8n aufhört, ist die Frage nicht, ob das Canvas hübsch ist. Sie ist, was an den zwei Rändern passiert die das Canvas nicht zeigt, wenn der Workflow denken muss und wenn er überleben muss. Wenn du den ganzen Stack ordentlich entworfen haben willst statt nur das einfache Drittel, genau dieses Gespräch führen wir.
