LangGraph vs. n8n: Den richtigen Agent-Orchestrator für 2026 wählen

Jedes Agentensystem hat zwei Schichten: die Reasoning-Schicht (ein LLM plus Werkzeuge) und die Orchestrierungsschicht (Zustand, Retries, Integrationen, Menschen). Die Modellwahl ist weniger entscheidend, als die meisten Teams glauben. Die Wahl des Orchestrators entscheidet, ob das System um 3 Uhr morgens betreibbar ist.

LangGraph und n8n beantworten die Orchestrierungsfrage aus entgegengesetzten Richtungen. LangGraph ist eine Python-Bibliothek für typisierte Graphen aus Knoten; n8n ist eine visuelle Laufzeit mit über 400 Integrationen und einem queue-basierten Worker-Pool.

LangGraph behandelt Zustand als typisiertes First-Class-Objekt. Jeder Knoten liest und schreibt einen Ausschnitt davon, und das Framework kann den gesamten Zustand nach jedem Schritt in Postgres oder Redis checkpointen. Ergebnis: fortsetzbare Langläufer-Agenten mit Time-Travel-Debugging.

n8n arbeitet mit per-Execution-JSON, das zwischen Knoten fließt. Das ist einfacher, schneller zu verstehen und leichter für nicht-technische Rollen — aber wiederaufnehmbare Mehrtages-Agenten musst du selbst in einem Postgres-Node persistieren.

Beide unterstützen Retries, aber mit unterschiedlicher Ergonomie:

• LangGraph — Knoten mit Retry-Policies dekorieren, mit tenacity oder eigener Middleware kombinieren. Fehler werfen Python-Exceptions, die du in expliziten Zweigen abfängst.
• n8n — jeder Knoten hat eingebaute Retries mit Exponential-Backoff, Error-Trigger pro Workflow und einen Queue-Modus, der Worker-Ausfälle vom Hauptprozess isoliert.

Bei semantischen Fehlern (falsche Tool-Argumente, Antwortverweigerung) brauchen beide eine Korrekturschleife zurück zum Planner. In LangGraph ist das eine Bedingungskante, in n8n ein Switch-IF-Muster — der Unterschied ist unwesentlich.

Hier hat LangGraph in Kombination mit LangSmith die klarste Story: jede Knotenausführung ist ein Trace mit Ein-/Ausgaben und Token-Zählern, und Evals können gespeicherte Traces erneut abspielen. n8n liefert Execution-Logs, Daten-Snapshots pro Knoten und eine durchsuchbare Execution-Liste — hervorragend für Ops, weniger strukturiert für Offline-Evals.

Pragmatisches Muster: Produktion auf n8n, 1%-Sample an eine LangGraph-Replay-Harness spiegeln. Du bekommst die Ops-Oberfläche von n8n und die Eval-Disziplin von LangGraph.

n8n gewinnt bei der Integrationsbreite um Größenordnungen — Slack-Approvals, Gmail, HubSpot, Notion und hunderte mehr mit verwalteten OAuth-Credentials. Dasselbe in LangGraph bedeutet: Tool-Wrapper schreiben und OAuth selbst verwalten.

Für jeden Workflow, in dem ein Mensch freigeben, prüfen oder editieren muss, ist der Wait-Node von n8n mit Webhook-Callback der kürzeste Weg von der Idee zur Produktion.

Das zuverlässigste Muster, das ich für Kunden ausliefere: n8n besitzt Ingress, Integrationen und Human-Handoff; ein einzelner Executor-Sub-Workflow ruft einen LangGraph-Service über HTTP für den Reasoning-Graph auf. Das Team bekommt n8n-Ops und LangGraph-Typisierung ohne Sieger-Wahl.

Ingress (n8n Webhook)
  → Payload validieren (n8n Function)
  → LangGraph-Service aufrufen (n8n HTTP Request)
      ← liefert { plan, tool_calls, final_answer }
  → Tools ausführen (n8n Sub-Workflows)
  → Human Review (n8n Slack + Wait)
  → Persistieren + benachrichtigen (n8n Postgres + Email)