Graph Engineering für KI-Code-Agenten: Kontext, Verträge und Reparatur
Was ein vertragsgesteuerter Agentengraph einem Entwickler beibrachte: begrenzter Kontext, deterministische Validierung, gezielte Reparatur sowie wann die zusätzlichen Rechenausgaben gerechtfertigt sind.
Quellen: Graph Engineering for AI Coding Agents: Beyond Prompt Loops
„Graph Engineering“ erhält in letzter Zeit viel Aufmerksamkeit, und die meisten Erklärungen konzentrieren sich auf Graphen, Knoten und DAGs. Diese Aspekte sind zwar wichtig, beantworten aber nicht die eigentliche Frage, die gestellt werden sollte: Warum bräuchten KI-Programmieragenten überhaupt plötzlich Graph Engineering?
Ein Entwickler, der Monate lang mit Tools wie Claude Code und später Codex gearbeitet hat, bemerkte ein Muster. Die meisten Programmieraufgaben scheitern nicht daran, dass das Modell keinen Code schreiben kann. Sie scheitern vielmehr daran, dass lang andauernde Workflows allmählich ihre Struktur verlieren. Der Kontext gerät aus dem Gleichgewicht, Anforderungen werden vergessen, Ausgaben sind schwer zu überprüfen, und wenn etwas schiefgeht, ist die einfache Lösung oft, die gesamte Aufgabe neu zu starten.
Diese Beobachtung führte zu einem kleinen Forschungsrahmen namens ContractGraph. Der folgende Überblick erläutert seine Konzepte, was funktionierte und was nicht. Er wurde nicht entwickelt, um mit bestehenden Frameworks zu konkurrieren, und er ist nicht an ein bestimmtes Modell gebunden. Das Ziel war enger gefasst: Kann ein Workflow so gestaltet werden, dass jeder Schritt ein klares Ziel, einen gut definierten Vertrag sowie eine deterministische Methode zur Entscheidung darüber hat, ob der Schritt tatsächlich abgeschlossen ist?
Das Ergebnis war ein durch Verträge gesteuertes Graphenmodell, das einen Forschungsworkflow über isolierte Aufgaben, explizite Validierung und gezielte Korrektur abwickelte, anstelle eines einzigen großen Prompts. Die erste Implementierung richtete sich an Forschungsagenten, doch die zugrunde liegenden Ideen gelten genauso gut für Programmieragenten, Dokumentenpipeline, Bewertungssysteme sowie jeden Prozess, bei dem mehrere von KI gesteuerte Schritte Ergebnisse liefern müssen, die überprüft werden können. Bedenken Sie, dass es sich um ein Experiment eines Praktikers handelt, weshalb die Schlussfolgerungen auf Erfahrung beruhen und keine gemessenen Benchmarks sind.
Was Graphenengineering bedeutet
Graphenengineering ist die Praxis, einen komplexen KI-Workflow in kleine Ausführungseinheiten aufzuteilen und diese mit expliziten Regeln miteinander zu verbinden. Ein durch Graphenengineering gestaltetes System kombiniert in der Regel mehrere Ausführungseinheiten, explizite Routing-Regeln, gemeinsamen Zustand, Validierung sowie dauerhafte Koordination.
Jeder Knoten hat eine einzige Verantwortung. Die Kanten bestimmen den nächsten Schritt. Der über den Workflow geteilte Zustand überträgt Informationen mit, und eine Überprüfungsphase entscheidet, ob weitergemacht, neu versucht, repariert oder gestoppt werden soll.
Die beiden Fragen hinter der Konzeption
Da der Entwickler erwartete, die meiste Zeit mit Knoten, Kanten und dem Ausführungsschritt zu verbringen, stellte er fest, dass das nicht der schwierige Teil war. Zwei Fragen kamen immer wieder auf.
Erstens: Welche Informationen sollte einem KI-Agenten erlaubt sein, als wahr zu betrachten? Zweitens: Wie kann man feststellen, dass die Ausgabe tatsächlich dem ursprünglichen Anliegen entspricht, nachdem eine Aufgabe abgeschlossen wurde?
Je mehr der lang andauernden Workflows getestet wurden, desto klarer wurde, dass diese Fragen wichtiger waren als das Diagramm selbst. Ein Agent, der mit falschen Informationen startet oder ohne zuverlässige Möglichkeit, seine Arbeit zu überprüfen, fertig wird, trägt einfach Fehler von einem Knoten zum nächsten weiter. Die beiden Fragen wurden zu Context und Contract. Der Context definiert, was ein Agent glauben darf, und der Contract definiert, was er erzeugen muss. Alles andere im Framework hängt von diesen beiden Konzepten ab.
Context und Verträge als Bausteine
Das Diagramm war nicht der schwierigste Teil. Die eigentliche Herausforderung bestand darin, sicherzustellen, dass jeder Knoten mit den richtigen Informationen startet und etwas Überprüfbares erzeugt, bevor der Workflow weitergeht.
Kontext. Agenten sollten nicht alles sehen. Ein Knoten erhält nur die Informationen, denen er vertrauen kann – beispielsweise Benutzeranforderungen, Projektbeschränkungen, überprüfte Dokumente oder von früheren Knoten akzeptierte Ergebnisse.
Vertrag. Jeder Knoten benötigt eine klare Definition dessen, was er liefern muss. Wenn ein Ergebnis nicht den Anforderungen des Vertrags entspricht, kann der Workflow nicht einfach weiterlaufen. Er sollte die Ausgabe überprüfen, den fehlerhaften Schritt beheben oder anhalten.
Einfach ausgedrückt: Der Kontext bestimmt, was ein Agent glauben darf, und die Verträge legen fest, was er liefern muss. Sobald beide Grenzen klar definiert sind, ist es viel einfacher, über das Graph zu reasoningen. Jeder Knoten hat eine einzige Aufgabe, eine eindeutige Quelle der Wahrheit, eine messbare Ausgabe sowie eine deterministische Kontrolle, bevor der nächste Schritt beginnt.
Von einer Idee zu einem ausführbaren Graph
Sobald Kontext und Verträge getrennt sind, stellt sich die nächste Frage: Wie werden sie zu einem ausführbaren Workflow? Es war nicht das Ziel, einen separaten Graphen für Forschung, Programmierung oder Dokumentenerstellung fest einzubauen. Stattdessen sollte der Workflow dynamisch aus dem Problem selbst kompiliert werden – nicht aus vordefinierten Pfaden. Zunächst müssen zwei Schritte ausgeführt werden.
Der erste Schritt beinhaltet den Aufbau des Kontexts. Nicht jede Datei oder jedes Dokument verdient gleichen Vertrauens, daher erstellt der Workflow einen kanonischen Kontext: eine überprüfte Quelle der Wahrheit, auf die alle Knoten zurückgreifen können. Die Rohmaterialien variieren je nach Aufgabe – beispielsweise Projektunterlagen, Anforderungen der Nutzer, Code, Designdokumente oder andere als zuverlässig eingestufte Eingaben.
Der zweite Schritt erstellt den Vertrag. Anstatt die Aufgabe allein in Prosa zu beschreiben, erzeugt er einen strukturierten Vertrag, der festlegt, was in jeder Phase erzeugt werden muss, wie sich die Knoten voneinander abhängen und was vor Fortsetzung der Ausführung validiert werden muss.
Sobald beide Elemente vorhanden sind, wird der Workflow kompiliert. Diese Initialisierungsphase führt nichts aus; ihre Aufgabe besteht im Planen. Aus ihr entstehen das Ausführungsgraphen, ein auf den jeweiligen Knoten zugeschnittenes Kontextpaket, wiederverwendbare Manifeste sowie gemeinsam genutzte Fähigkeiten, zusätzlich eine aus den Verträgen abgeleitete Ausführungsreihenfolge ohne fest programmierte Abfolge.
Die Ausführung verläuft anschließend einfach. Ein Knoten erhält lediglich seinen auf ihn zugeschnittenen Kontext, erledigt seine zugewiesene Arbeit, durchläuft eine deterministische Validierung, speichert das akzeptierte Ergebnis und gibt die Kontrolle weiter. Fällt die Validierung fehl, wird nur der betroffene Knoten repariert, bevor die Ausführung fortgesetzt wird – somit muss nichts von vorne beginnen.
Die Struktur des Graphen stammt daher aus dem Kontext sowie den zu Beginn bereitgestellten Kontrakten und nicht aus einer festgelegten Implementierung. Derselbe Kompilierungsprozess kann Workflows für Forschung, Programmierung, Dokumentation oder etwas völlig anderes zusammenstellen, ohne die Laufzeit zu verändern.
Testen auf größeren und kleineren Modellen
Das Entwerfen eines Frameworks ist nur die halbe Miete. Die schwierigere Frage ist, ob die Architektur standhält, sobald ein Workflow groß genug ist, um ihre Schwächen aufzuzeigen.
Bei den ersten Experimenten wurde ein weitaus größeres Workflow in Claude Code verwendet, der dynamisch generierte Ausführungsknoten, verschachtelte Planungsstufen sowie lange Forschungsaufgaben enthielt. Die Qualität war hervorragend, doch die Fertigstellung des Workflows erforderte eine große Menge an Rechenleistung des Modells.
Das führte zu einer weiteren Frage: Könnte dieselbe Graph-Architektur immer noch zu zuverlässigen Workflows auf einem viel kleineren, günstigeren Modell führen? Ein zweites Experiment nutzte einen Workflow zur Erstellung von Studienplänen, der über OpenCode mit Big Pickle statt mit einem State-of-the-Art-Modell ausgeführt wurde. Die Mechanismen blieben unverändert: Der Workflow wurde dynamisch kompiliert, spezialisierte Knoten wurden erzeugt, jede Phase wurde deterministisch überprüft, Fehler wurden bei Bedarf behoben, und das endgültige Ergebnis entstand durch denselben Prozessablauf.
Das Ziel bestand nicht darin, Modelle miteinander zu vergleichen oder einen Gewinner zu küren. Es ging darum herauszufinden, inwieweit die Zuverlässigkeit von der Ausführungsarchitektur und nicht von den reinen Fähigkeiten des Modells stammte. Die überraschende Erkenntnis war, dass die größten Probleme überhaupt keine Modellfehler waren, sondern Workflow-Fehler – und genau hier wurde die Graph-Engineerung interessant.
Wo es versagte
Das Experiment zeigte nicht, dass das Graph-Engineering Ausfälle verhindert. Es zeigte vielmehr, dass das Graph-Engineering Ausfälle sichtbar macht.
Unterwegs traten alle möglichen Probleme auf: unvollständige Metadaten, fehlende Beweise, ungelöste Verweise, doppelte Inhalte, ungültige Lebenszykluszustände, falsche Trace-Informationen und sogar reine Kodierungsprobleme. Das Graph verursachte keines dieser Probleme. Es handelt sich dabei um die Ausfälle, die man von langlaufenden AI-Arbeitsabläufen erwarten würde.
Was sich änderte, war, dass jeder Ausfall einen genauen Ort hatte. Anstatt den gesamten Ablauf als eine fehlgeschlagene Ausführung zu betrachten, war es möglich, den spezifischen Knoten zu finden, der sein Versprechen nicht einhielt, nur diesen Knoten zu reparieren, erneut eine deterministische Validierung durchzuführen und von dort aus fortzufahren. Der Rest des Arbeitsablaufs blieb unverändert, da jede erfolgreiche Phase bereits überprüft und gespeichert worden war.
Das veränderte die Sichtweise des Entwicklers auf diese Technik. Es handelte sich nicht um eine Methode, um Modelle intelligenter zu machen, sondern um eine Möglichkeit, Fehler lokal zu machen, sichtbar zu machen und wieder gutzumachen. Das Diagramm beseitigte die Fehler nicht, aber es gab jedem Fehler eine Adresse.
Warum Validierung deterministisch sein muss
Ein Modell kann mit voller Sicherheit behaupten, dass eine Aufgabe abgeschlossen ist – doch das macht sie noch nicht wahr. Sprachmodelle können sehr gut argumentieren, zusammenfassen und entscheiden, doch sie sind kein zuverlässiger Beurteiler dafür, ob ein Workflow seine eigenen Anforderungen erfüllt hat.
Deshalb endet jeder Knoten in ContractGraph mit einer deterministischen Überprüfung. Niemand bittet ein zweites Modell um eine Meinung zum Ergebnis. Der Workflow prüft objektive Bedingungen: Enthält das Schema alle benötigten Felder? Sind die Abhängigkeiten erfüllt? Sind die erforderlichen Artefakte vorhanden und lösen sich die Referenzen auf? Hat der Knoten alles übergeben, was sein Vertrag verspricht? Es handelt sich dabei nicht um subjektive Beurteilungen – jede ist einfach wahr oder falsch.
Diese Trennung erwies sich als eine der wertvollsten Ideen im Framework. Das Modell konzentriert sich auf das Reasoning, während die deterministische Validierung die Überprüfung übernimmt. Ein Modell kann behaupten, seine Arbeit sei abgeschlossen, doch nur ein deterministischer Validator kann nachweisen, dass ein erforderliches Feld fehlt.
Warum sich die zusätzliche Mühe lohnen kann
Bereits vor diesem Experiment betrachtete der Entwickler die KI-Programmieragenten als ein kleines Team und nicht als einen einzelnen Assistenten. Es war nicht ungewöhnlich, dass Claude Code, Codex und OpenCode gleichzeitig an verschiedenen Teilen eines Repositoriums arbeiteten.
Das führte zu einem unerwarteten Problem. Die Agenten konnten gezwungen sein, dieselben Dateien zu ändern oder sich auf dieselbe Implementierung zu verlassen, und ohne Koordination konnte einer die Arbeit des anderen überschreiben oder früher getroffene Annahmen ungültig machen.
Die Lösung war einfach: Jede Aufgabe hatte einen Verantwortlichen. Wenn ein Agent für einen Teil des Codebases zuständig war, konnten die anderen diese Dateien nicht bearbeiten, bis der Verantwortliche es erlaubte. Durch eine Validierungsprüfung nach jedem wichtigen Schritt erreichten viele Konflikte das Repositorium nie.
Der Kompromiss war offensichtlich. Diese Entwicklungsart erfordert weitaus mehr Ressourcen als das Anfordern an ein Modell, eine Funktion in einem einzigen Gespräch zu erstellen, denn jeder Schritt der Validierung, des Neversuchs, der Korrektur und der Koordination verursacht zusätzliche Arbeit. Dennoch wirkte das Ergebnis anders. Anstatt ständig Regressionen zu beheben, die durch frühere Korrekturen entstanden waren, wurde der Arbeitsablauf viel vorhersehbarer, und Funktionen, die auf diese Weise entwickelt wurden, benötigten kaum Nacharbeiten, da jede Phase vor Beginn der nächsten überprüft wurde.
Graph-Engineering ist keine Methode, die bei jedem Prompt verwendet werden sollte – bei kleinen Änderungen handelt es sich dabei um reine Overhead-Kosten. Bei größeren Funktionen, langwierigen Implementierungen oder mehragentigen Aufgaben lohnt sich die zusätzliche Kostenbelastung, da dadurch etwas Wertvolleres als nur eine billige Inferenz erreicht wird: Vertrauen.
Was es wirklich kostet
Niemand sollte dies als Behauptung verstehen, dass Graph-Engineering eine Allheilmethode ist. Die Vorbereitung des Kontexts, die Erstellung von Verträgen, die Kompilierung des Graphen, die Validierung sowie die Reparatur und Aggregation erfordern jeweils zusätzliche Modellaufrufe und Tokens. Im Vergleich zu einem einzelnen Prompt ist der Arbeitsablauf zweifellos teurer.
Die frühesten Experimente mit frontier-Modellen lieferten hervorragende Ergebnisse, verbrauchten aber viel Rechenleistung – was ein Hauptgrund für das Testen kleinerer, günstigerer Modelle war. Die Lehre daraus ist, dass Graph-Engineering die Rechenleistung nicht verringert, sondern sie gezielt umverteilt. Anstatt Rechenleistung darauf zu verwenden, sich von Regressionen zu erholen, fehlgeschlagene Arbeitsabläufe neu zu starten oder wiederholt Fehler nachzubessern, verwendet das System sie im Voraus für Planung, Überprüfung und Isolierung von Fehlern.
Das ändert das Optimierungsziel. Graph Engineering ist nicht dafür konzipiert, die günstigste Ausführung zu erzielen, sondern die am besten vorhersehbare. Ein einziger OpenCode-Aufruf verbrauchte eine große Menge an Tokens. Diese Zahl sollte nicht als Beweis dafür angesehen werden, dass dieser Ansatz kostengünstig ist. Im Gegenteil: Sie zeigt gerade das Gegenteil, da Graph Engineering bewusst mehr Rechenleistung aufwendet, um Fehlerisolation, Überprüfbarkeit, Wiederaufnahmemöglichkeit und Zuverlässigkeit zu gewährleisten. Ob das ein guter Kompromiss ist, hängt vollständig vom Problem ab.
Wann es sich lohnt
Graph Engineering ist nicht für jeden AI-Arbeitsablauf notwendig. Für SQL-Abfragen, kleine Funktionen oder einige UI-Anpassungen reicht in der Regel ein gut formulierter Prompt aus, und das Hinzufügen von Verträgen, Validierungs-Ebenen sowie Ausführungsgraphen würde die Prozesse nur verlangsamen und komplizierter machen.
Es beginnt zu funktionieren, wenn die Kosten eines Fehlschlags die Kosten für zusätzliche Berechnungen übersteigen. Dazu gehören lang andauernde Forschungen, umfangreiche Aufgaben mit vielen Eigenschaften, mehragentige Arbeitsabläufe, sicherheitskritische Systeme, Unternehmensautomatisierung sowie jeder Prozess, dessen Ergebnis überprüfbar und reproduzierbar sein muss. Je mehr Schritte ein Arbeitsablauf hat, desto wichtiger wird eine explizite Koordination.
Die wichtigste Erkenntnis hat nichts mit Intelligenz zu tun. Wo ein Arbeitsablauf kompliziert ist, macht die Struktur es einfacher, ihn zu verfolgen, zu überprüfen, wiederherzustellen und zu erweitern. Die Idee ist außerdem noch lange nicht ausgereift. Ausführung unter Berücksichtigung von Abhängigkeiten, intelligenterere Scheduling-Methoden, Ressourcenoptimierung, Neukompilierung von Teilgraphen sowie eine verbesserte Koordination zwischen Agenten sind alles noch unerforscht. Kurze Zusammenfassung der Erkenntnis: Nutzen Sie Anweisungen, um Aufgaben zu lösen, und nutzen Sie Graphen-Engineering, um Systeme zu erstellen.
Zusammenfassende Gedanken
Zu Beginn bestand die Erwartung, etwas über Graphen zu lernen. Was die Übung tatsächlich vermittelte, waren Grenzen, Überprüfung und Koordination. Der Graph war nicht das Wichtigste. Entscheidend waren ein klarer Zweck für jeden Schritt, eine Beschränkung dessen, was ein Agent glauben darf, eine Definition dessen, was er erzeugen muss, sowie ein Nachweis der Fertigstellung, bevor etwas weitergeht.
Das ist nicht die einzige Möglichkeit, KI-Systeme zu entwickeln, und nicht jeder Arbeitsablauf benötigt so viel Struktur. Für komplexe, lang andauernde oder mehragentige Aufgaben bietet das Graphen-Engineering jedoch einen praktischen Weg zu Systemen, die vorhersehbarer sind und leichter weiterentwickelt werden können.
Falls man sich nur einen Satz merken muss, soll es dieser sein: Eine Anweisung formuliert den Wunsch, der Kontext legt fest, was der Agent als Fakt akzeptieren kann, der Vertrag beschreibt das zu liefernde Ergebnis, und der Graph ist das Mechanismus, der zeigt, dass die Arbeit abgeschlossen ist.
Zu Zeit dieses Experiments war ContractGraph noch in Entwicklung, und sein Repository war noch nicht veröffentlicht, da die Architektur zunächst vereinfacht werden sollte. Für eine umfassendere Einführung in das Thema suchen Sie am besten nach einem allgemeinen Leitfaden zur Graphenverarbeitung, da dieser Artikel nur ein einzelnes Framework behandelt und nicht den gesamten Bereich abdeckt.
Verwandte Literatur
- Wie KI-Code-Agenten die Arbeit von Entwicklern im Jahr 2026 verändern — KI-Code-Agenten sind von der Autocomplete-Funktion zu der Bearbeitung ganzer Aufgaben übergegangen. Informationen zu Adoption, Kontextverarbeitung, typischem Code, Überprüfung sowie MCP und welche Veränderungen für Junior- und Senior-Entwickler eintreten.