Graph Engineering
- Methoden
- Jan 2024
- ab Jan 2026
Der Entwurf von Nodes, Edges und State, mit dem ein Agenten-Workflow abnahmefähig wird — statt den Agenten selbst über den Ablauf entscheiden zu lassen.
Graph Engineering ist die Disziplin, einen KI-Workflow als gerichteten Graph zu entwerfen: Nodes sind die Arbeitsschritte, Edges legen die erlaubten Übergänge zwischen ihnen fest, und ein gemeinsamer State wandert hindurch. Statt einem Agenten die Ablaufkontrolle zu überlassen, schreibt Graph Engineering die Wege fest, die er nehmen darf.
Was der Graph festlegt — und was der Agent noch entscheidet
Ein frei laufender Agent bekommt ein Ziel, Werkzeuge und einen Prompt und entscheidet dann selbst, was als Nächstes passiert. Das trägt für offene Aufgaben und wird unzuverlässig, sobald ein Prozess wiederholbar, prüfbar oder abnahmefähig sein muss.
Graph Engineering dreht die Verantwortung um: Der Ablauf wird zur Entwurfsentscheidung des Teams statt zur Laufzeitentscheidung des Modells. Das Modell entscheidet weiterhin, was es innerhalb eines Schritts tut — aber nicht mehr, welcher Schritt als Nächstes kommt.
Der Preis dafür ist Vorarbeit. Wer einen Graph baut, muss vorher wissen, welche Schritte es gibt und woran man erkennt, dass einer fehlgeschlagen ist. Genau diese Klärung ist der eigentliche Gewinn — sie erzwingt eine Prozessdefinition, die viele Teams vorher nie schriftlich hatten.
- Aufgabe → Node: Entwurf
- Node: Entwurf → Node: Prüfung
- Node: Prüfung → Bedingte Edge: Mängel gefunden?
- Bedingte Edge: Mängel gefunden? → Node: Entwurf
- Bedingte Edge: Mängel gefunden? → Ergebnis
Die vier Bausteine
Node — ein begrenzter Arbeitsschritt. Ein Node kann ein Modellaufruf sein, ein Werkzeugaufruf, deterministischer Code, eine menschliche Freigabe oder ein vollständiger Agent mit eigener innerer Schleife. Nicht jeder Node braucht ein Modell: Was sich ausrechnen lässt, gehört in normalen Code.
Edge — ein erlaubter Übergang. Direkte Edges bilden feste Reihenfolgen ab, bedingte Edges verzweigen anhand des States: Freigabe, Rückgabe, Eskalation, Abbruch. Was keine Edge hat, kann nicht passieren. Das ist der ganze Punkt.
State — der gemeinsame Kontext. Ein typisiertes Objekt, das an den Edges entlangwandert und von jedem Node gelesen und ergänzt wird: Briefing, Quellen, Zwischenstand, Mängelliste, Anzahl der Durchläufe.
Guard — die Entscheidungsregel. Eine Routing-Funktion wählt die nächste Edge, eine Guard-Bedingung prüft, ob der Übergang erlaubt ist. Beides ist gewöhnlicher Code, kein Prompt — und damit testbar.
from langgraph.graph import END, START, StateGraph
builder = StateGraph(State) # State = typisiertes Dict
builder.add_node("entwurf", schreibe_entwurf)
builder.add_node("pruefung", pruefe_entwurf)
builder.add_edge(START, "entwurf") # feste Edge
builder.add_edge("entwurf", "pruefung")
builder.add_conditional_edges( # bedingte Edge
"pruefung", route, {"nacharbeiten": "entwurf", "fertig": END}
)
graph = builder.compile()
Ein Redaktions-Workflow mit vier Rollen
Ausgangssituation. Ein Team veröffentlicht regelmäßig technische Fachartikel. Ein einzelner Agent mit gutem Prompt liefert brauchbare Entwürfe, aber unvorhersehbar: mal prüft er Fakten, mal nicht, mal hält er die Tonalität, mal nicht. Für einen redaktionellen Prozess mit Freigabe reicht das nicht.
Ziel. Ein Ablauf, in dem jede Prüfung garantiert stattfindet und jede Rückgabe nachvollziehbar ist.
Ablauf. Aus dem Themenbriefing sammelt eine Researcher-Node Quellen und legt sie im State ab. Eine Writer-Node erzeugt daraus einen Entwurf. Eine SEO-Node prüft Suchintention und Überschriftenlogik, eine Fact-Checker-Node validiert die Aussagen gegen die gesammelten Quellen. Erst danach finalisiert eine Editor-Node Sprache und Struktur.
Entscheidungspunkte. Findet die Fact-Checker-Node einen sachlichen Fehler, geht der Entwurf mit Kommentar zurück an die Writer-Node — nicht an den Anfang. Meldet die SEO-Node eine verfehlte Suchintention, geht er ebenfalls zurück, aber mit einem anderen Kommentartyp. Ein Zähler im State begrenzt die Runden: Nach drei erfolglosen Durchläufen bricht der Graph ab und übergibt an einen Menschen, statt weiterzudrehen.
Ergebnis. Jeder veröffentlichte Artikel hat nachweislich alle Prüfungen durchlaufen. Der State enthält am Ende die vollständige Historie — welche Node was bemängelt hat, in welcher Runde. Das ist der Unterschied zwischen „die KI hat das geschrieben" und einem Prozess, den man abnehmen kann.
- Themenbriefing → Researcher
- Researcher → Writer
- Writer → SEO-Prüfung
- SEO-Prüfung → Writer
- SEO-Prüfung → Fact Checker
- Fact Checker → Writer
- Fact Checker → Editor
- Editor → Freigegebener Artikel
- Fact Checker → Übergabe an Mensch
from typing import Literal, TypedDict
from langgraph.graph import END, START, StateGraph
class Redaktion(TypedDict):
briefing: str
quellen: list[str]
entwurf: str
maengel: list[str]
runden: int
def nach_seo(state: Redaktion) -> Literal["writer", "checker"]:
# Routing ist gewöhnlicher Code — testbar, ohne Modellaufruf
return "writer" if state["maengel"] else "checker"
def nach_faktencheck(
state: Redaktion,
) -> Literal["writer", "editor", "mensch"]:
if not state["maengel"]:
return "editor"
if state["runden"] >= 3:
return "mensch" # Notausgang statt Endlosschleife
return "writer"
builder = StateGraph(Redaktion)
for name, fn in NODES.items(): # researcher, writer, seo, checker, ...
builder.add_node(name, fn)
builder.add_edge(START, "researcher")
builder.add_edge("researcher", "writer")
builder.add_edge("writer", "seo")
builder.add_conditional_edges("seo", nach_seo)
builder.add_conditional_edges("checker", nach_faktencheck)
builder.add_edge("editor", END)
builder.add_edge("mensch", END)
graph = builder.compile()
Wo der Harness aufhört und der Graph anfängt
Ein Sprachmodell allein ist kein Agent. Es hat kein Gedächtnis zwischen zwei Aufrufen, keine Schleife und keine Möglichkeit, ein Werkzeug tatsächlich auszuführen — es kann nur die Absicht formulieren, eines zu benutzen. Was daraus einen Agenten macht, ist der Harness: die Laufzeitschicht, die das Modell wiederholt aufruft, seine Ausgabe interpretiert, Werkzeugaufrufe ausführt, Ergebnisse zurückspeist und entscheidet, wann Schluss ist. Dazu gehören Kontextverwaltung, Speicher, Wiederholungen, Zeitlimits, Budgetgrenzen, Berechtigungsprüfungen und Tracing. Die inzwischen verbreitete Kurzformel dafür lautet: Agent = Modell + Harness.
Graph Engineering setzt eine Ebene darüber an. Der Harness macht einen einzelnen Agenten handlungsfähig; der Graph sorgt dafür, dass mehrere Agenten, Werkzeuge, Prüfungen und Menschen in einer nachvollziehbaren Ordnung zusammenwirken. Beide Ebenen greifen ineinander: Ein Node kann ein vollständiger Agent mit eigenem Harness und eigener innerer Schleife sein — von außen bleibt er ein Kasten mit definierten Ein- und Ausgängen.
Diese Trennung hat eine praktische Konsequenz. Fehlverhalten innerhalb eines Schritts — abgeschnittene Antworten, ignorierte Werkzeuge, überlaufender Kontext — ist ein Harness-Problem. Fehlverhalten zwischen Schritten — eine Prüfung wird übersprungen, ein Prozess dreht endlos, eine Freigabe fehlt — ist ein Graph-Problem. Teams, die beides nicht trennen, versuchen Ablauffehler mit besseren Prompts zu beheben.
Wann sich der Aufwand rechnet
Ein Graph lohnt sich, sobald ein Ergebnis abgenommen werden muss: wenn mehrere Rollen oder Werkzeuge zusammenspielen, wenn Qualitätsprüfungen garantiert stattfinden sollen, wenn ein Mensch an einer bestimmten Stelle freigeben muss, oder wenn im Nachhinein nachvollziehbar sein muss, warum ein Durchlauf so ausgegangen ist.
Er lohnt sich nicht bei offener Exploration. Wo der nächste sinnvolle Schritt erst aus dem Ergebnis des letzten hervorgeht — Recherche in unbekanntem Terrain, Fehlersuche, kreatives Ausprobieren — behindert ein vorgezeichneter Pfad mehr, als er absichert. Dort ist ein frei laufender Agent mit gutem Harness die bessere Wahl. Die Frage ist nicht „Graph oder Agent", sondern: Kennen wir die erlaubten Wege vorher?
Wo es reproduzierbar schiefgeht
Der Graph wird zum Ablaufdiagramm. Wenn jeder Node ein Modellaufruf ist, hat man Komplexität hinzugefügt, ohne Zuverlässigkeit zu gewinnen. Alles Berechenbare gehört in deterministischen Code.
Rückschleifen ohne Zähler. Zwei Nodes, die sich gegenseitig zurückweisen, laufen bis zum Budgetlimit. Jede Schleife braucht eine Abbruchbedingung im State — und einen Ausgang für den Fall, dass sie greift.
Der State wächst unkontrolliert. Hängt jeder Node alles an, läuft irgendwann das Kontextfenster über. Was ein Node sieht, ist eine eigene Entwurfsentscheidung.
Vorzeitige Struktur. Einen Prozess zu modellieren, den man selbst noch nicht verstanden hat, zementiert falsche Annahmen. Erst manuell durchspielen, dann bauen.
Abgrenzung und Herkunft
Weiterentwicklung von Loop Prompting. Eine Schleife ist bereits ein Graph — ein gerichteter, zyklischer. Loop Prompting beschreibt den einfachsten Fall: ein Pfad, mehrfach durchlaufen. Graph Engineering verallgemeinert ihn um Verzweigung, Parallelität und Zusammenführung.
In Abgrenzung zu Graph Prompting. Graph Prompting spannt den Denkprozess als Graph auf — Knoten sind Teilgedanken innerhalb einer Aufgabe. Graph Engineering spannt den Arbeitsprozess auf — Knoten sind Schritte in einem Ablauf. Ähnliches Bild, verschiedene Ebenen: eine Reasoning-Struktur gegenüber einer Systemarchitektur.
In Abgrenzung zum Prompt Engineering. Prompt Engineering optimiert einen einzelnen Modellaufruf. Graph Engineering entscheidet, welche Aufrufe es überhaupt gibt, in welcher Reihenfolge sie stattfinden und woran man erkennt, dass einer misslungen ist.
Ergänzt durch Context Engineering. Context Engineering bestimmt, was ein Modell in einem Schritt sieht. Graph Engineering bestimmt, welche Schritte es gibt. Beide arbeiten am selben State, aus verschiedenen Richtungen.
Hervorgegangen aus der Workflow-Automatisierung. Die Bausteine sind alt: Zustandsmaschinen, Prozess-Engines, gerichtete Graphen. Neu ist nur, dass einzelne Knoten jetzt Sprachmodelle sein können. Greifbar wurde die Praxis mit LangGraph ab Januar 2024; als eigener Begriff hat sich „Graph Engineering" erst 2026 durchgesetzt — die Sache ist älter als ihr Name.
Warum der State die eigentliche Entwurfsentscheidung ist
Die meisten Teams entwerfen zuerst die Nodes, dann die Edges — und behandeln den State als Restgröße, in die man alles hineinlegt, was unterwegs anfällt. Das ist die falsche Reihenfolge, und man merkt es erst spät.
Der State entscheidet über drei Dinge, die später nicht mehr billig zu ändern sind. Erstens: worauf sich routen lässt. Eine bedingte Edge kann nur prüfen, was im State steht — existiert die Mängelliste nur als Fließtext in der letzten Modellantwort, ist sie für den Graph unsichtbar. Zweitens: was sich fortsetzen lässt. Ein Durchlauf, der nach einer menschlichen Freigabe weiterlaufen soll, muss vollständig aus dem State rekonstruierbar sein. Drittens: was sich prüfen lässt. Nachvollziehbarkeit ist kein Logging-Feature, das man hinterher ergänzt — sie entsteht, wenn im State steht, wer was in welcher Runde bemängelt hat.
Ein praktischer Test vor dem Bauen: Formuliere jede Verzweigung als Satz über den State — „wenn die Mängelliste nicht leer ist und weniger als drei Runden gelaufen sind". Lässt ein Satz sich nicht so formulieren, fehlt ein Feld. Die Übung dauert eine halbe Stunde und ersetzt die erste Umbaurunde.
Aus Prompts einen Prozess machen
Wir entwickeln Agenten-Workflows mit klaren Rollen, Bedingungen und Qualitätsprüfungen — und mit einem State, der eine Abnahme trägt.