Agent Chat UI: ein Next.js-Frontend für beliebige LangGraph-Server

Welches Problem die App tatsächlich löst

Ein LangGraph-Server liefert über seine API Runs, Threads und State, aber keine Oberfläche. Wer einen Graphen testet, steht vor der Wahl, für jede Iteration ein eigenes Chat-Frontend zu bauen oder mit curl und einem Notebook zu arbeiten. Agent Chat UI füllt genau diese Lücke: eine Next.js-Anwendung, die laut README mit jedem LangGraph-Server spricht, dessen State einen messages-Schlüssel enthält. Die Zielgruppe sind Entwickler, die einen Agenten oder Graphen lokal oder als Deployment betreiben und dessen Ausgaben im Browser sehen wollen, ohne UI-Arbeit zu investieren. Das Projekt liefert außerdem eine gehostete Instanz unter agentchat.vercel.app, sodass sich ein Server auch ohne lokalen Klon ansprechen lässt. Der Nutzen endet dort, wo eine eigene Produktoberfläche mit Branding, Rollen oder mehreren Ansichten gebraucht wird. Die App ist ein Inspektionswerkzeug, kein Baukasten für ein Endnutzerprodukt.

Wie die Verbindung zu einem Graphen aufgebaut wird

Die App fragt vor dem ersten Chat vier Angaben ab: die Deployment URL des LangGraph-Servers, die Assistant- oder Graph-ID, optional einen LangSmith API Key und einen Schalter für Agent-Builder-Deployments. Diese Werte landen im Chat-Kontext und werden für jede Anfrage an den Server verwendet. Der Schalter setzt laut README das Authentifizierungsschema automatisch auf langsmith-api-key. Der Datenfluss ist damit ungewöhnlich direkt: der Browser des Nutzers spricht mit dem LangGraph-Server, es gibt im Standardaufbau keine vermittelnde Backend-Schicht. Genau das macht die lokale Einrichtung so kurz und ist zugleich die Ursache des Produktionsproblems, das weiter unten beschrieben wird. Der State des Graphen ist die zweite Schnittstelle. Die Komponenten lesen Nachrichten aus dem messages-Schlüssel, und Zusatzdaten wie Artifacts hängen an thread.meta.artifact. Wer den messages-Schlüssel nicht bedient, bekommt keine Darstellung.

Start in wenigen Befehlen, mit und ohne Setup-Formular

Zwei Wege führen zum laufenden Frontend. Der eine ist der Generator: npx create-agent-chat-app. Der andere ist der Klon des Repositories, gefolgt von pnpm install und pnpm dev, wonach die App unter http://localhost:3000 erreichbar ist. Das Setup-Formular lässt sich überspringen, indem die Datei .env.example nach .env kopiert und gefüllt wird. Drei Schlüssel nennt das README: NEXT_PUBLIC_API_URL, NEXT_PUBLIC_ASSISTANT_ID und NEXT_PUBLIC_AUTH_SCHEME. Ein Beispiel aus der Dokumentation setzt NEXT_PUBLIC_API_URL auf http://localhost:2024 und NEXT_PUBLIC_ASSISTANT_ID auf agent. Für Agent-Builder-Deployments gehört in NEXT_PUBLIC_AUTH_SCHEME der Wert langsmith-api-key. Nach Änderungen an der Datei muss die Anwendung neu gestartet werden, sonst greifen die Werte nicht. Sobald diese Variablen gesetzt sind, erscheint das Formular nicht mehr. Wer mehrere Server parallel testet, verliert damit die bequeme Umschaltung im Browser und muss die Datei anpassen.

Nachrichten gezielt aus der Oberfläche heraushalten

Zwei Mechanismen steuern die Sichtbarkeit von Nachrichten, und sie unterscheiden sich in der Reichweite. Der erste unterbindet nur das Live-Streaming: Wird dem Chat-Modell der Tag langsmith:nostream mitgegeben, etwa über .with_config in Python oder .withConfig in TypeScript, emittiert der Server keine on_chat_model_stream-Ereignisse für dieses Modell. Die Oberfläche rendert Streaming normalerweise genau aus diesen Events. Das README weist ausdrücklich darauf hin, dass die Nachricht danach trotzdem erscheint, wenn sie unverändert im State des Graphen gespeichert wird. Der zweite Mechanismus verhindert die Anzeige dauerhaft. Dazu bekommt die Nachricht vor dem Speichern die ID-Präfixierung do-not-render-, kombiniert mit dem Tag langsmith:do-not-render am Modell. Die UI filtert jede Nachricht heraus, deren ID mit diesem Präfix beginnt. Das ist ein wirksamer Filter, aber ein grober: er arbeitet auf einem String-Präfix, nicht auf einer Rollen- oder Metadatenprüfung. Wer versehentlich eine sichtbare Nachricht mit diesem Präfix versieht, sieht sie nie wieder in der Oberfläche.

Artifacts als zweiter Kanal neben dem Chat

Antworten müssen nicht im Chatverlauf stehen. Die App kann Inhalte in einem Seitenpanel rechts neben dem Chat darstellen. Der Zugriff läuft über thread.meta.artifact, und das README liefert einen Hook useArtifact, der diesen Kontext zurückgibt. Der Hook gibt ein Tupel aus einer Komponente und einem Objekt mit open, setOpen, context und setContext zurück. Eine Komponente rendert dann ihren sichtbaren Teil im Chat und den ausführlichen Inhalt im Panel, gesteuert über setOpen. Das Muster passt zu Fällen, in denen ein Modell einen langen Text, Code oder Bericht erzeugt, der den Verlauf sonst fluten würde. Der Preis ist Kopplung: Der Artifact-Kontext hängt am Meta-Feld des Threads, also muss der Graph diese Struktur liefern. Die Dokumentation zeigt den Hook und ein Beispiel, beschreibt aber nicht, wie sich mehrere Artifacts pro Thread verhalten oder wie der Kontext zwischen Renders überlebt. Wer das braucht, muss den Code lesen.

Der Produktionsweg führt über einen Proxy

Der wichtigste Abschnitt des README ist der über den Gang in die Produktion, und er ist zugleich der unbequemste. Im Standardaufbau verbindet sich der Client direkt mit dem LangGraph-Server. Für eine öffentliche Instanz funktioniert das nicht, weil dann jeder Nutzer einen eigenen LangSmith API Key mitbringen und die LangGraph-Konfiguration selbst setzen müsste. Die Dokumentation nennt zwei Wege zur Authentifizierung und beschreibt den schnelleren davon: das Paket langgraph-nextjs-api-passthrough, das Anfragen an den LangGraph-Server weiterleitet und den LangSmith API Key serverseitig anhängt. Nutzer brauchen dann keinen eigenen Schlüssel. Das ist eine Architekturentscheidung mit Folgen: Das Frontend wird zum Proxy für einen privilegierten Schlüssel, und wer die Route öffentlich erreichbar macht, muss selbst dafür sorgen, dass nicht jeder beliebige Runs gegen das eigene Konto auslösen kann. Das README endet an dieser Stelle und nennt die zweite Option nicht mehr im gelieferten Text. Wer die App produktiv betreibt, sollte diese Lücke als offene Aufgabe behandeln, nicht als Detail.

Wann ein anderes Werkzeug die bessere Wahl ist

Wenn das Ziel nicht die Inspektion eines Graphen ist, sondern ein eingebetteter Assistent in einer bestehenden Anwendung, ist Agent Chat UI der falsche Ausgangspunkt. Die App bringt ihre eigene Seitenstruktur, ihre eigene Setup-Maske und ihr eigenes Verständnis von Threads mit. Ein Projekt, das nur einen Chatbereich in eine vorhandene Oberfläche einfügen will, kämpft gegen diese Struktur an, statt sie zu nutzen. Der Unterschied zu einem generischen Chat-Frontend liegt in der Kopplung: Agent Chat UI kennt LangGraph-Konzepte wie Assistant-IDs, Threads, den messages-Schlüssel und Artifact-Metadaten direkt. Ein generisches Frontend müsste diese Semantik über eine eigene API-Schicht nachbilden, hätte dafür aber freie Hand bei Authentifizierung und Datenmodell. Für Teams, die ohnehin eine eigene Backend-Schicht betreiben, ist der Vorteil der direkten Verbindung kein Vorteil mehr. Dann bleibt vor allem die fertige Chatdarstellung, und die lässt sich mit geringerem Integrationsaufwand selbst bauen.

Pflege, Lizenz und was vor dem Einsatz zu klären ist

Das Repository steht unter der MIT-Lizenz, die Weitergabe und Anpassung erlaubt, solange Lizenz- und Urheberrechtshinweis erhalten bleiben. Für ein internes Werkzeug ist das unkritisch. Wer die App jedoch als gehosteten Dienst für Dritte betreibt, sollte prüfen, ob die Weitergabe der angepassten Quellen den eigenen Auslieferungsprozess berührt. Das ist keine Rechtsberatung, sondern ein Hinweis auf den Punkt, an dem die Lizenz praktisch relevant wird. Zum Wartungsaufwand lässt sich aus dem Material nur begrenzt etwas sagen: Das Repository ist nicht archiviert und der letzte Push datiert auf den 9. September 2026, veröffentlichte Releases wurden nicht abgerufen. Die App hängt an Next.js, an pnpm und an der LangGraph-Client-Bibliothek, sodass ein Upgrade der Kette in der Regel auch hier Anpassungen verlangt. Vor dem Einsatz zu klären sind drei Dinge: ob der eigene Graph den messages-Schlüssel führt, ob NEXT_PUBLIC_AUTH_SCHEME gesetzt werden muss, und ob der Proxy den API Key serverseitig hält, statt ihn an den Browser durchzureichen. Erst danach ist die Frage nach der Oberfläche sinnvoll.

Redaktionelles Fazit

Für lokale Entwicklung und Demos ist Agent Chat UI die schnellste Variante, einen LangGraph-Server sichtbar zu machen: npx create-agent-chat-app, pnpm dev, fertig. Wer das Frontend öffentlich betreiben will, braucht zuerst eine Entscheidung über die Authentifizierung, weil der Standardaufbau jeden Nutzer nach einem eigenen LangSmith API Key fragt. Vor dem Deployment zu prüfen sind der Inhalt von .env.example, ob NEXT_PUBLIC_AUTH_SCHEME auf langsmith-api-key gesetzt werden muss, und ob der gewählte Proxy das Format der Anfragen unverändert weiterreicht.

Offizielle Quellen

1. Issues
2. langchain-ai/agent-chat-ui on GitHub
3. License: MIT
4. Project website
5. README