Graph Engineering: Klare Abhängigkeiten vor Agentenzahl
Graph Engineering ordnet Arbeit, Daten und Prüfungen zwischen KI-Agenten. Ein konkreter Ablauf zeigt sinnvolle Grenzen und den Weg zum verifizierten Ergebnis.
TL;DR
Graph Engineering beschreibt hier die Abhängigkeiten zwischen Arbeitsschritten, Daten und Prüfungen. Ich zeige an einem zweisprachigen Artikel, wann Parallelität hilft und warum ein Wiederanlauf mehr braucht als gespeicherte Ergebnisse. Die Agentenzahl ist dabei keine Qualitätsmetrik.
Graph Engineering wurde zuletzt gern über große Agentenzahlen erklärt. Mich interessiert eine kleinere Frage: Welcher Schritt muss worauf warten?
Wenn zwei Agenten gleichzeitig denselben Text verbessern, habe ich zunächst zwei Fassungen. Noch kein besseres Ergebnis. Wenn dagegen einer Quellen prüft und ein anderer die Darstellung im Browser, können beide unabhängig arbeiten. Vor der Veröffentlichung brauche ich ihre Ergebnisse gemeinsam. Diese Unterschiede muss der Ablauf ausdrücken können.
Graph Engineering heißt für mich: die Abhängigkeiten der Arbeit so entwerfen, dass Ausführung, Prüfung und Wiederanlauf zusammenpassen. Nicht mehr Agenten starten, sondern die Übergänge zwischen ihren Aufgaben klären.
Was Boris Cherny tatsächlich beschreibt
Ausgangspunkt für diesen Text waren Posts über Boris Cherny, den Entwickler von Claude Code. Im Gespräch mit Diana Hu bei Y Combinator beschreibt er ab etwa 24:42 im Video dynamische Workflows: Arbeit aufteilen, Ergebnisse prüfen, danach gegebenenfalls weitere Agenten einsetzen. Davon unterscheidet er wiederkehrende Loops und Routinen.
Im veröffentlichten Transkript finde ich weder den Ausdruck „Graph Engineering“ noch die verbreitete 85-Prozent-Zahl. Ich verwende den Begriff deshalb als technische Einordnung, nicht als Cherny-Zitat oder offizielle Anthropic-Methode. Den wichtigeren Gedanken nehme ich mit: Ein Agent braucht eine Möglichkeit, seine Arbeit zu überprüfen. Seine Laufzeit allein sagt wenig aus.
Graph Engineering beginnt vor dem ersten Agenten
Ein Ausführungsgraph beschreibt Arbeitsschritte und ihre Beziehungen. Ein Knoten kann ein Modellaufruf sein, aber ebenso ein Compiler, ein Datenbank-Read oder ein Mensch mit einer Entscheidung. Eine Kante sagt, warum ein Schritt vor einem anderen stattfinden muss.
Das ist nicht dasselbe wie ein Knowledge Graph. Hier modellieren wir keinen Wissensbestand, sondern einen Ablauf.
Auch eine einfache Kette ist ein Graph. Sie ist nicht automatisch schlecht. Wenn ich erst eine Datei erzeugen und anschließend genau diese Datei prüfen muss, ist die Reihenfolge richtig. Die Frage ist, ob jede Warteposition einen Grund hat.
Ein häufiger Grund ist eine Datenabhängigkeit. Die englische Fassung benötigt den geklärten Inhalt. Daneben gibt es aber andere Gründe: Zwei Schritte schreiben in dieselbe Datei, teilen ein knappes API-Limit oder verändern denselben Release-Zustand. Nur weil kein Ergebnis direkt weitergereicht wird, sind die Schritte noch nicht unabhängig.
Ich notiere deshalb für jeden Schritt Eingang, Ergebnis, Schreibbereich und Abschlussbedingung. Das klingt nach Verwaltungsarbeit. Tatsächlich spart es die spätere Diskussion darüber, was ein Agent mit „fertig“ gemeint hat.
Ein Beispiel: ein zweisprachiger Fachartikel
Nehmen wir einen Ablauf wie diesen Artikel. Quellen und vorhandene Inhalte werden zunächst gesammelt. Daraus entsteht eine gemeinsame Liste belastbarer Aussagen. Erst dann werden die Sprachfassungen ausgearbeitet.
Quellen + bestehende Artikel
|
geprüfte Aussagen
/ \
DE-Fassung EN-Fassung
\ /
Bedeutungsabgleich
/ \
Linkprüfung Browserprüfung
\ /
Veröffentlichungspaket
|
Veröffentlichung prüfen
Das ist ein Entwurfsbeispiel, kein Protokoll eines parallel ausgeführten Produktionslaufs. Die zwei Sprachfassungen dürfen auf demselben geklärten Inhalt aufbauen. Sie müssen aber vor Veröffentlichung auf Bedeutungsgleichheit geprüft werden: Behauptet die Übersetzung plötzlich eine Garantie, die im deutschen Text nicht steht? Ist aus einem Vorschlag ein bereits ausgeliefertes Feature geworden?
Linkprüfung und Browserprüfung haben unterschiedliche Aufgaben. Ein HTTP-200-Status beweist nicht, dass der Link zum richtigen Inhalt führt. Ein lesbarer Screenshot beweist nicht, dass die englische Canonical-URL stimmt. Ich will diese Befunde nicht in einer einzigen Bewertung „sieht gut aus“ verlieren.
Die Übergabe braucht mehr als Fließtext
Ein Agent soll nicht einfach „alles geprüft“ zurückgeben. Für diesen Ablauf wäre ein Ergebnis mit Artikel-ID, Sprache, Quellenstand, gefundenen Problemen und Prüfstatus nützlicher. Dazu gehört ein Verweis auf das tatsächlich geprüfte Artefakt.
Ein Schema hilft, fehlende Felder und falsche Typen zu erkennen. Es beweist nicht, dass die Aussage stimmt. Ein sauber formatiertes Objekt kann genauso falsche Quellen oder erfundene Ergebnisse enthalten wie ein Absatz. Deshalb prüft ein deterministischer Schritt die Form, während eine fachliche Prüfung die Behauptungen mit ihren Belegen vergleicht.
Die Dokumentation zu dynamischen Workflows zeigt einen konkreten technischen Weg: Die Koordination liegt in einem ausführbaren Skript, statt nur im Gesprächsverlauf. Für das Architekturprinzip ist aber nicht entscheidend, welches Werkzeug dieses Skript ausführt.
Ein lokaler Fehler soll lokal bleiben
Wenn nur ein englischer Absatz unbelegt ist, muss nicht die gesamte Recherche erneut laufen. Der betroffene Abschnitt geht mit einem konkreten Befund zurück. Die deutsche Fassung bleibt vorläufig erhalten.
Vorläufig ist hier wichtig. Ändert die Korrektur eine gemeinsame Aussage, werden auch ihre abhängigen Ergebnisse ungültig. Dann muss der Bedeutungsabgleich erneut laufen. Ein guter Graph kennt also nicht nur den nächsten Schritt, sondern auch, welche früheren Bestätigungen eine Änderung entwertet.
Das gilt ebenso für unterbrochene Läufe. Ein gespeichertes Ergebnis ist ein Checkpoint, keine Garantie, dass alle Außenwirkungen genau einmal passiert sind. Wurde die Veröffentlichung bereits ausgelöst, aber ihre Antwort ging verloren, darf der Wiederanlauf nicht blind erneut veröffentlichen. Er muss den tatsächlichen Zustand lesen. LangGraphs Dokumentation zur Persistenz macht diese Trennung zwischen gespeichertem Ausführungszustand und Wiederaufnahme konkret.
Der entscheidende Teil eines Agentengraphen ist oft die Kante, über die ein unbestätigtes Ergebnis nicht weiterkommt.
Mehr Parallelität muss sich rechnen
Ich messe nicht nur, wie schnell die Arbeiter fertig sind. Zur Laufzeit gehören auch Zusammenführung, Prüfung und Nacharbeit. Zur Rechnung gehören sämtliche Modellaufrufe, inklusive verworfener Versuche.
Die sinnvolle Vergleichsgröße ist ein akzeptiertes Ergebnis. Wie lange dauert es vom Auftrag bis zum geprüften Artefakt? Was kostet es? Wie oft braucht es eine Korrektur? Wie viel Aufmerksamkeit bleibt bei mir hängen?
Ein Graph mit vielen gleichzeitig laufenden Knoten kann bei diesen Fragen schlechter abschneiden als eine kurze Kette. Anthropic beschreibt schon in Building effective agents, dass zusätzliche Komplexität durch einen tatsächlichen Nutzen begründet sein sollte. Ein kleines Beispiel sauber zu messen ist hilfreicher als eine fremde Agentenzahl nachzubauen.
Wo das in meiner Arbeit hinpasst
Mein Beitrag über Harness Design beschreibt die Umgebung eines Agenten: Kontext, Werkzeuge und Prüfungen. Der Graph ergänzt die Frage, wie mehrere Arbeitsschritte zusammenhängen. Eine begrenzte Prüfschleife kann wiederum innerhalb eines einzelnen Knotens liegen. Das sind verschiedene Perspektiven auf dasselbe System, keine Rangliste neuer Berufstitel.
Bei session-orchestrator ist die Wellenstruktur eine konkrete Form dieser Organisation. Auf Agentic Builders, meiner Lernplattform, behandeln die Materialien dazu unter anderem getrennte Schreibbereiche und Prüfungen zwischen Wellen. Das Prinzip lässt sich auch ohne mein Tool anwenden.
Ich würde mit einem vorhandenen Ablauf beginnen und seine Wartepositionen markieren. Danach einen begrenzten Bereich parallelisieren, seine Ergebnisse getrennt prüfen und den gesamten Durchlauf mit der einfachen Variante vergleichen. Wenn daraus kein besseres Ergebnis entsteht, bleibt die einfachere Variante.
Das ist auch der Maßstab meiner Arbeitsweise. Wenn du einen konkreten Ablauf besprechen möchtest, erreichst du mich über Kontakt. Die nützlichste erste Skizze hat oft nur wenige Knoten.
Häufige Fragen
Was bedeutet Graph Engineering bei KI-Agenten?
Hier bezeichnet es den Entwurf von Arbeitsschritten, Abhängigkeiten und Prüfgrenzen eines agentischen Ablaufs. Entscheidend ist, welche Ergebnisse ein Schritt benötigt und unter welchen Bedingungen der nächste starten darf.
Ist Graph Engineering dasselbe wie ein Knowledge Graph?
Nein. Ein Knowledge Graph beschreibt Wissen und Beziehungen zwischen Entitäten. Dieser Artikel behandelt den Ausführungsgraphen von Aufgaben, Datenflüssen und Zustandsübergängen.
Brauche ich dafür viele Agenten oder ein neues Framework?
Nein. Auch ein kurzer Ablauf mit einem Modell und normalen Funktionen kann ein sinnvoller Graph sein. Zusätzliche Agenten sollten einen gemessenen Vorteil gegenüber dem einfacheren Ablauf bringen.