LangGraph.js: Agenten als Graph, nicht als Kette

Welches Problem der Graph löst

Die meisten LLM-Anwendungen beginnen als lineare Kette: Prompt rein, Antwort raus. Sobald ein Agent mehrere Werkzeuge aufrufen, zwischendurch auf eine menschliche Freigabe warten oder nach einem Absturz weiterlaufen soll, reicht diese Form nicht mehr. Genau hier setzt LangGraph.js an. Das README beschreibt das Projekt als "low-level orchestration framework for building stateful agents", also als Orchestrierungsschicht unterhalb der Komfortbibliotheken. Zustand ist kein Nebeneffekt, sondern das zentrale Objekt: Der Graph hält ihn, die Knoten verändern ihn, die Kanten entscheiden, wohin es weitergeht. Die Zielgruppe sind damit nicht Einsteiger, die ihren ersten Chatbot bauen, sondern Entwicklerteams, die einen Ablauf mit Verzweigungen, Wiederholungen und Unterbrechungspunkten in TypeScript abbilden wollen. Das README nennt als Anwendungsfälle ausdrücklich durable execution, human-in-the-loop, kurz- und langfristiges Gedächtnis sowie Deployment. Wer keinen dieser Punkte braucht, bekommt hier vor allem zusätzliche Begriffe.

Knoten, Kanten, Zustand: die Mechanik

LangGraph.js modelliert den Ablauf als Graphen. Ein Knoten ist eine Funktion, die den aktuellen Zustand liest und eine Aktualisierung zurückgibt; eine Kante verbindet Knoten und kann bedingt sein, sodass der nächste Schritt vom Zustand abhängt. Das README verweist für die Details auf die API-Referenz, in der die Graph- und Checkpointing-APIs sowie vorgefertigte Komponenten dokumentiert sind. Zwei Inspirationsquellen nennt das Projekt selbst: Pregel und Apache Beam für das Ausführungsmodell, NetworkX für die öffentliche Schnittstelle. Das ist mehr als eine Fußnote, denn es erklärt die Denkweise. Statt einen Agenten als Schleife mit Abbruchbedingung zu schreiben, definiert man einen Graphen, dessen Kanten die Schleife bilden. Der Vorteil zeigt sich, sobald der Lauf unterbrochen wird: Ein Checkpointer schreibt den Zustand zwischen den Schritten fort, und die Ausführung kann laut Dokumentation an genau der Stelle fortgesetzt werden, an der sie aufgehört hat. Interrupts erlauben es, den Zustand vor dem nächsten Knoten zu inspizieren und zu verändern. Wer schon einmal versucht hat, eine verschachtelte Tool-Schleife mitten im Lauf anzuhalten, erkennt den Unterschied sofort.

Installation und die zwei Pakete

Die Installation ist knapp gehalten. Das README gibt genau eine Zeile vor: npm install @langchain/langgraph @langchain/core. Beide Pakete gehören zusammen, das Core-Paket liefert die Basistypen, auf denen die Graph-APIs aufsetzen. Wer bereits LangChain in einem Projekt nutzt, hat den zweiten Teil oft schon im Baum. Ein Beispiel für einen minimalen Graphen steht im README nicht, dafür verweist es auf die Dokumentation und die API-Referenz. Das ist eine bewusste Entscheidung: Das Projekt positioniert sich als Bibliothek mit Referenzcharakter, nicht als Tutorial mit Copy-Paste-Einstieg. Für die Konfiguration ist aus dem vorliegenden Material nur wenig belegbar. Sicher ist, dass Checkpointing und Interrupts über eigene APIs laufen, deren Schlüssel und Optionen in der API-Referenz dokumentiert sind. Konkrete Config-Keys lassen sich aus dem README nicht ableiten, und ich gebe hier keine erfundenen Namen an. Wer die Persistenz anbindet, sollte mit der Checkpointing-Dokumentation beginnen, nicht mit dem README.

Wo der Ansatz an Grenzen stößt

Ein Graph ist ein Vertrag über Kontrollfluss, und Verträge kosten. Jede Verzweigung, jeder Wiederholungsversuch und jede Unterbrechung muss explizit modelliert werden. Bei einem Agenten, der einfach nur ein paar Werkzeuge hintereinander aufruft, entsteht dadurch mehr Struktur als Nutzen. Dazu kommt die Kopplung an das Ökosystem: Zwar betont das README, LangGraph lasse sich ohne LangChain verwenden, doch die naheliegenden Integrationspunkte, Observability und Evaluierung laufen über LangSmith, und für schnelle Agenten verweist das Projekt selbst auf Deep Agents als höhere Ebene. Wer LangGraph.js wählt, wählt also eine Basis, auf der er selbst baut. Ein weiterer Punkt ist die Reife der JavaScript-Seite gemessen an der Python-Seite. Das README nennt beide Bibliotheken als gleichwertig, doch die Versionsstände der veröffentlichten Pakete zeigen etwas anderes: Die jüngsten Releases betreffen die UI-Integrationen @langchain/react, @langchain/vue und @langchain/svelte, alle in Version 1.0.36-rc.1 und damit als Release Candidate. Das ist kein Qualitätsurteil, aber ein Hinweis darauf, dass sich die Randbereiche des Ökosystems noch bewegen.

Was stattdessen in Frage kommt

Wer keine Graphstruktur braucht, sondern eine Agentenschleife mit Planung, Unteragenten und Dateisystemzugriff, wird im selben Projekt auf Deep Agents verwiesen. Der Unterschied liegt nicht im Umfang, sondern in der Ebene: Deep Agents nimmt einem die Schleife ab, LangGraph.js gibt einem die Bausteine für eine eigene. Ein zweiter Vergleichspunkt ist die Python-Variante LangGraph. Das README führt sie als äquivalente Bibliothek mit eigener Dokumentation. Die praktische Differenz ist weniger die Funktionalität als die Umgebung: TypeScript-Projekte bleiben im selben Typsystem und derselben Build-Kette, Python-Projekte profitieren vom dortigen Ökosystem für Datenverarbeitung und Modellwerkzeuge. Wer bereits einen TypeScript-Backenddienst betreibt und den Agenten dort einbetten will, spart sich mit LangGraph.js einen zweiten Dienst. Wer dagegen vor allem mit Notebooks und Python-Bibliotheken arbeitet, gewinnt durch einen Wechsel nach JavaScript wenig.

Wartung, Versionen und Lizenz

Das Repository ist nicht archiviert, der letzte Push datiert auf den 9. September 2026, und die Release-Kandidaten für die UI-Pakete stammen vom selben Tag. Das deutet auf aktive Pflege hin, sagt aber nichts über die Stabilität der Kern-APIs. Wer auf Release Candidates setzt, sollte damit rechnen, dass sich Details zwischen Versionen ändern. Für die Wartung bedeutet das: Die Abhängigkeit auf @langchain/langgraph und @langchain/core sollte gepinnt werden, und Upgrades gehören in einen eigenen Testlauf mit den eigenen Graphen, nicht in einen Routine-Bump. Die Lizenz ist MIT, angegeben im Repository. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, den Lizenztext und den Urheberrechtshinweis beizubehalten. Das ist eine Einordnung, keine Rechtsberatung; wer die Bibliothek in einem Produkt mit eigenen Lizenzauflagen einbettet, klärt die Details besser mit der eigenen Rechtsabteilung. Ein Kostenfaktor, der nicht in der Lizenz steht, ist der Betrieb: Checkpointing braucht eine Persistenzschicht, und deren Betrieb ist Teil der Gesamtkosten.

Für wen sich der Einstieg lohnt

Der Aufwand liegt nicht in der Installation, sondern im Entwurf. Wer den Graphen zeichnet, bevor er ihn schreibt, kommt schneller voran als jemand, der die Struktur während des Codierens entstehen lässt. Die Dokumentation deckt die Kernkonzepte ab, das README bleibt bewusst knapp und verweist für alles Weitere auf die API-Referenz und einen kostenlosen Kurs. Das ist ein Hinweis darauf, wo die Zeit hingeht: nicht in das Lesen einer Startseite, sondern in das Verständnis von Zustandsmodell, Checkpointing und Interrupts. Wer diese drei Begriffe nicht in einem Satz erklären kann, ist mit einer höheren Abstraktionsebene besser bedient.

Redaktionelles Fazit

Adoptieren sollten LangGraph.js Teams, die Agenten mit Unterbrechungen, Wiederaufnahme nach Fehlern und explizitem Zustand in TypeScript betreiben und die Bereitschaft mitbringen, Graphstruktur und Checkpointer selbst zu entwerfen. Nicht geeignet ist es für Projekte, die lediglich einen einzelnen Prompt mit etwas Tool-Aufruf brauchen, und für Teams, die eine fertige Agentenschleife mit Planung und Dateisystemzugriff erwarten; dafür verweist das Projekt selbst auf Deep Agents. Vor dem ersten Produktiveinsatz sollte man konkret prüfen, welcher Checkpointer vorgesehen ist und ob die eigene Persistenzschicht dessen Anforderungen erfüllt, denn davon hängen durable execution und Interrupts ab. Ohne diese Entscheidung bleibt der Graph ein Ablaufdiagramm ohne Gedächtnis.

Offizielle Quellen

1. langchain-ai/langgraphjs on GitHub
2. License: MIT
3. Project website
4. README
5. Releases