Graph Engineering: Wann sich Agenten-Graphen lohnen

Vor einem Monat drehte sich die Diskussion um KI-Agenten fast ausschließlich um Loops. Dann schrieb Peter Steinberger am 18. Juli 2026 einen Satz auf X — „Are we still talking loops or did we shift to graphs yet?” — und ein Teil der Szene erklärte Loops über Nacht für erledigt. Der Beitrag erreichte binnen zwei Tagen rund 2,6 Millionen Aufrufe.

Die Pointe traf, weil sie halb stimmt. Ein Loop ist ein Agent, der eine Sache wiederholt verbessert: ausführen, prüfen, korrigieren, erneut ausführen. Was seitdem diskutiert wird, geht darüber hinaus — ein Graph aus Loops, also ein Netz, in dem sich mehrere Zyklen gegenseitig kontrollieren, statt dass ein Agent allein auf eine Kennzahl optimiert.

Der Einwand kam innerhalb weniger Stunden: Das ist eine jahrzehntealte Idee aus der Informatik unter neuem Namen. Der Einwand ist berechtigt, und genau das spricht für die Sache. Ein Muster, das seit dreißig Jahren kritische Systeme trägt, bringt den Reifegrad mit, den produktive Arbeit braucht.

Dieser Leitfaden ordnet ein, was ein Graph konkret ist, welcher Test die Laufzeit sofort senkt, welches Muster sich in der Praxis rechnet, wo diese Architekturen brechen und wann ein Graph das falsche Werkzeug ist.

Was ein Graph konkret ist

Ein Graph ist ein aufgezeichneter Plan für KI-Arbeit. Er beantwortet zwei Fragen:

1. Welche Aufgaben müssen erledigt werden?
2. Welche Aufgabe muss auf welche warten?

Dafür reichen zwei Bauteile:

• Knoten (die Box): eine Aufgabe. Ein Agent, der genau eine Sache erledigt, mit definiertem Input und definiertem Output — etwa einen Wettbewerber recherchieren, einen Entwurf schreiben, eine Behauptung prüfen.
• Kante (der Pfeil): eine Abhängigkeit. Eine Aufgabe braucht das Ergebnis einer anderen und muss deshalb warten. Eine Kante zählt nur, wenn tatsächlich Daten über sie fließen.

Knoten denken, Kanten transportieren Ergebnisse.

Der Knoten-Vertrag

Brauchbar wird ein Knoten im Graph durch einen strikten Vertrag: eine abgegrenzte Aufgabe, ein definierter Input, ein definierter Output.

▸ KNOTEN-VERTRAG
  AUFGABE: Preise eines Wettbewerbers recherchieren (genau diese eine Aufgabe)
  IN:      { competitor: "string", url: "https://..." }
  OUT:     { price: number, plan: string, source: "url", date: "YYYY-MM-DD" }
  SCHEMA:  Erzwungen. Freitext wird abgelehnt und erneut angefordert.
  GRUND:   Ein definierter Output lässt den nächsten Knoten weiterarbeiten,
           ohne zu raten.

Der Fake-Edge-Test

Gehen Sie den KI-Workflow durch, den Sie heute betreiben, Schritt für Schritt. An jedem Schritt steht eine Frage:

Braucht dieser Schritt tatsächlich das Ergebnis des unmittelbar vorherigen?

• Ja: Die Kante ist echt. Die Reihenfolge bleibt.
• Nein: Es gibt keine Kante, das Warten ist verschenkt. Beide Aufgaben können gleichzeitig laufen.

Beispiel: Code-Review

Der lineare Ablauf lautet „prüfe Datei A auf Fehler, dann Datei B”. Die Prüfung von Datei B schaut jedoch nie in das Ergebnis von Datei A. Beide laufen nur deshalb nacheinander, weil die Anweisung so getippt wurde. Als Graph laufen sie nebeneinander, und der Durchlauf dauert so lange wie die langsamere der beiden Dateien statt so lange wie beide zusammen.

Ihr aktuelles Setup ist bereits ein Graph

Wer einen Agenten mit „mach A, dann B, dann C, dann D” anweist, hat einen Graphen gezeichnet. Es ist eine einzelne gerade Kette, in der jeder Knoten einen Pfeil hinein und einen hinaus hat.

Das hat zwei Konsequenzen. Erstens die Laufzeit: Ein linearer Ablauf mit 40 Schritten hat die addierte Latenz aller 40 Schritte. Zweitens die Bruchstelle: Bleibt Knoten C hängen, läuft Knoten D nie an, und die Arbeit davor bleibt im Ablauf gefangen.

Entfernt man die Fake-Edges, fällt die lange Kette in eine breitere Struktur zusammen — mehrere unabhängige Aufgaben laufen nebeneinander und speisen einen Knoten, der sie zusammenführt.

Die gezeichnete Reihenfolge bestimmt die Laufzeit oft stärker als die Geschwindigkeit des Modells. In Praxisberichten fallen Durchlaufzeiten nach dem Umbau von Minuten auf Sekunden; belastbare Zahlen hängen allerdings stark vom konkreten Workload ab, weil der Gewinn genau so groß ist wie der Anteil echt unabhängiger Schritte.

Das Muster, das sich rechnet: der Diamant

Für den Anfang braucht es keine hundert Formen. In produktiven Systemen taucht immer wieder dieselbe Grundform auf: der Diamant, formal Fan-out, Reduce, Synthese.

1. Fan-out: Breite gewinnen, indem mehrere Worker parallel laufen.
2. Reduce: Rohbefunde mit deterministischem Code verdichten und filtern, ohne dafür Tokens auszugeben.
3. Synthese: Die geprüften Ergebnisse mit einem starken Modell zusammenführen.

Der wirtschaftliche Hebel liegt im mittleren Schritt. Deduplizieren, filtern und sortieren erledigt gewöhnlicher Code zuverlässiger und zu Nullkosten; das teure Modell sieht am Ende nur noch das, was übrig bleibt.

// A Market-Scan Graph — The Diamond Pattern
const angles = [
  "pricing vs the top 3 competitors",
  "what buyers complain about in reviews",
  "the feature gaps in the category",
  "where the market moves in the next 12 months",
];

// 1. FAN OUT — Parallel collection with cheap, structured nodes
const raw = await parallel(
  angles.map(a => () => agent({
    task: `research: ${a}. Every claim needs a source url + date.`,
    schema: Finding,        // Enforced JSON structure
    model: "cheap-model",   // Cost-effective model for collection
  }))
);

// 2. REDUCE — Deterministic code execution (Zero Token Cost)
const findings = dedupeBySource(raw.flat().filter(Boolean));

// 3. VERIFY — Independent verifiers using fresh contexts
const survivors = await parallel(
  findings.map(f => () => agent({
    task: "Try to disprove this. Return keep | drop + why.",
    input: f,
    freshContext: true,     // Isolated execution context
    model: "strong-model",  // High-reasoning model for evaluation
  }))
).then(v => findings.filter((_, i) => v[i].verdict === "keep"));

// 4. SYNTHESIZE — Final report generation
return agent({
  task: "Write one unified report, ranked by confidence with sources attached.",
  input: survivors,
  model: "strong-model"
});

Der Prüfer trägt die Zuverlässigkeit

Selbstprüfung innerhalb desselben Kontexts funktioniert selten. Modelle übersehen eigene Fehler, wenn sie ihre vorherigen Ausgaben erneut lesen — die fehlerhafte Annahme steht bereits im Kontextfenster und wird als gegeben behandelt.

Daraus folgt eine harte Regel: Der Agent, der die Arbeit erzeugt hat, prüft sie nie selbst.

▸ PRÜFER-KNOTEN
  INPUT:      Ein Befund aus einem Worker (nur Daten, kein Gesprächsverlauf)
  KONTEXT:    Frisch und isoliert
  PRÜFUNGEN:  Parallel entlang von drei Kriterien:
              1. Korrektheit: Trägt die Behauptung logisch?
              2. Aktualität:  Ist die zugrunde liegende Quelle aktuell?
              3. Beleg:       Stützt die angegebene URL die Behauptung direkt?
  ENTSCHEID:  Angenommen nur bei Mehrheit der Prüfer.

Teilen sich Worker und Prüfer ein Kontextfenster, fällt der Graph auf einen einzelnen Loop zurück, der seine eigene Arbeit bewertet.

Wo Graphen brechen

Kontext-Kollaps

Fächert man auf hunderte Knoten auf und kippt deren Rohausgaben in einen einzigen Synthese-Knoten, sprengt das die Kontextgrenze. Die Gegenmaßnahme ist ein gestaffelter Fan-in: Ergebnisse in Blöcke schneiden, jeden Block zusammenfassen, dann die Zusammenfassungen synthetisieren.

// Layered Fan-In Architecture
const batches = chunk(results, 40); // Partition into groups of 40
const summaries = await parallel(
  batches.map(b => () => agent({ task: "Summarize batch", input: b }))
);

return agent({ task: "Synthesize final output", input: summaries });

Scheinbare Unabhängigkeit

Zwei Knoten sehen im Code unabhängig aus, konkurrieren aber um dieselbe Ressource — sie schreiben in dasselbe Verzeichnis oder laufen gegen dasselbe API-Rate-Limit. Die Gegenmaßnahme ist Isolation der Ausführungsumgebung, etwa ein eigener Git-Worktree oder ein eigener Dateinamensraum pro Worker.

// Workspace Isolation Pattern
await parallel(files.map(f => () => agent({
  task: `Refactor ${f}`,
  worktree: true, // Isolated environment per worker
})));

Stiller Knotenausfall

In parallelen Graphen fällt ein ausgefallener Knoten nicht auf. Die übrigen Ergebnisse werden zu einem Bericht verdichtet, der vollständig aussieht und es nicht ist. Die Gegenmaßnahme ist eine explizite Zählprüfung beim Zusammenführen.

// Fan-In Integrity Guard
const results = (await parallel(jobs)).filter(Boolean);
if (results.length < jobs.length) {
  flag(`WARNING: ${jobs.length - results.length} of ${jobs.length} nodes failed.`);
}

Wann ein Graph das falsche Werkzeug ist

Graphen optimieren Breite und gleichzeitiges Volumen. Sie verbessern nicht die Urteilsqualität eines einzelnen Schrittes.

Graph sinnvoll, wenn …	Graph überflüssig, wenn …
die Arbeit in unabhängige Teilaufgaben zerfällt	die Aufgabe klein, isoliert oder eng sequenziell ist
große Datenmengen gleichzeitig zu verarbeiten sind	jeder Schritt manuell freigegeben werden muss
Durchlaufzeit über viele Aufgaben kritisch ist	die Aufgabe explorativ ist und das Ziel offen
sich an jedem Schritt ein striktes Output-Schema erzwingen lässt	jede Teilaufgabe wirklich auf dem Vorgänger aufbaut

Ground-Truth-Anker

Topologie allein sichert keine Korrektheit. Ein Graph, in dem jeder Knoten einen anderen Knoten validiert, kann geschlossen halluzinieren, solange alle Knoten ausschließlich auf generierten Ausgaben arbeiten. Am Ende steht dann ein Konsens über einen Fehler.

Deshalb brauchen Graphen Anker — Knoten, die an deterministische, nicht verhandelbare Signale gebunden sind:

• ausgeführte Testsuiten mit pass/fail-Status
• direkte Datenbankabfragen oder echte API-Antworten
• externe Validierungssysteme mit eigener Wahrheitsquelle

Ein Anker unterscheidet einen prüfenden Graphen von einem, der sich selbst bestätigt.

Graphen mit Claude Code beschreiben

Aktuelle Werkzeuge lassen die Orchestrierung als Spezifikation in natürlicher Sprache formulieren, die eine Ausführungsumgebung wie Claude Code abarbeitet. Die Koordination läuft dann auf Skriptebene, statt über fortlaufenden Chat Kontext zu verbrauchen.

▸ GRAPH-SPEZIFIKATION (Beispiel)

ZIEL:       Jede Route-Datei unter src/routes/ auf fehlende Auth-Prüfungen
            untersuchen.

FAN OUT:    Ein Agent pro Datei, parallel.
VERIFY:     Unabhängiger Prüfer pro Befund, frischer Kontext.
CAP:        Erster Lauf auf 20 Dateien begrenzt.
ON FAIL:    Fehlende oder fehlgeschlagene Dateien markieren, nicht still
            überspringen.
REPORT:     Eine zusammengeführte Übersicht verwundbarer Routen.

Drei Vorlagen für den produktiven Einsatz

▸ GRAPH-SPEZIFIKATION: Recherche-Desk

ZIEL:         Ein entscheidungsreifer Recherchebericht zu [Thema].

FAN OUT:      Fünf getrennte Analysewinkel, Rechercheure parallel.
REGEL:        Jede Behauptung braucht Quelllink und Datum.
VERIFY:       Ein frischer Skeptiker-Knoten prüft jede Behauptung;
              Unbelegtes fällt raus.
MERGE:        Überlebende zu einem nach Konfidenz sortierten Bericht.
SAVE:         Export nach `research-report.md`.
HUMAN GATE:   Freigabe abwarten, bevor Änderungen angewendet werden.

▸ GRAPH-SPEZIFIKATION: Content-Pipeline

ZIEL:         Ein publikationsreifer Fachentwurf zu [Thema].

PARALLEL:     1. Struktur der bestbewerteten Wettbewerber analysieren.
              2. Reale Suchanfragen der Zielgruppe extrahieren.
              3. Lücken in der vorhandenen Literatur identifizieren.
MERGE:        Befunde zu einer Gliederung verbinden, Entwurf schreiben.
VERIFY:       Faktenprüfer markiert jede unbelegte Aussage.
SAVE:         Ausgabe nach `drafts/`, markierte Stellen hervorgehoben.
HUMAN GATE:   Menschliche Prüfung vor Veröffentlichung.

▸ GRAPH-SPEZIFIKATION: Refactoring-Durchlauf

ZIEL:       Funktionen über 100 Zeilen in `src/` finden und Refactorings
            vorschlagen.

FAN OUT:    Ein Analyse-Agent pro Datei, parallel.
VERIFY:     Unabhängiger Prüfer bewertet jeden Änderungsvorschlag im
            frischen Kontext.
DEDUPE:     Doppelte Vorschläge zusammenführen.
CAP:        Maximal 50 Dateien pro Lauf.
REPORT:     Übersicht analysierter gegenüber geänderter Dateien.

Was das kostet

Auffächern erhöht Rechenzeit und Tokenverbrauch. Ein Graph skaliert den Durchsatz, nicht die Effizienz des einzelnen Modellaufrufs — dieselbe Arbeit wird schneller fertig und kostet dabei mehr.

Die derzeit größte öffentlich dokumentierte Referenz ist die Portierung des Bun-Runtimes von Zig nach Rust. Rund 535.000 Zeilen Zig wurden in elf Tagen in über eine Million Zeilen Rust überführt, verteilt auf etwa 50 Workflows mit bis zu 64 parallel laufenden Claude-Agenten und 6.778 Commits. Die Rechnung dafür lag bei etwa 165.000 US-Dollar an API-Kosten. Die Reaktionen darauf gingen weit auseinander — der Zig-Erfinder Andrew Kelley kritisierte das Ergebnis öffentlich als ungeprüft. Genau das ist der Punkt: Der Graph liefert Durchsatz, die Prüfung bleibt eine eigene Verantwortung.

Für den Einstieg gilt deshalb die umgekehrte Reihenfolge: mit niedrigen Knotengrenzen starten (etwa CAP: 10), Kontextverbrauch und Ergebnisqualität messen, dann schrittweise hochziehen.

Zusammenfassung

1. Abhängigkeiten prüfen: Mit dem Fake-Edge-Test finden, welche Schritte gleichzeitig laufen können.
2. Kontexte trennen: Erzeugung und Prüfung strikt in getrennten Kontextfenstern halten.
3. Ergebnisse verankern: Mit deterministischen Signalen validieren — Tests, Schemata, echte Ausführung.
4. Kontrolliert skalieren: Mit expliziten Obergrenzen arbeiten und den Tokenverbrauch bei breiten Läufen im Blick behalten.

---

Dieser Text ist die deutsche Bearbeitung eines Beitrags von Anatoli Kopadze zum Thema Graph Engineering, ergänzt um eigene Einordnung und überprüfte Quellenangaben.