Der Nachfolger von THE Loop Engineering und der Workflow, der deine Agents 10x breiter laufen lässt...
Die meisten Leute, die einen mehrstufigen Agenten bauen, landen bei einer geraden Linie
Schritt eins, Schritt zwei, Schritt drei. Jeder wartet, bis der letzte fertig ist, bevor er beginnt.
Hier ist, was fast niemand überprüft:
die Hälfte dieser Schritte musste nie warten
Sie reihen sich einfach ein, ein Job nach dem anderen, bis der Kontextfenster voll ist und der Agent vergisst, was er tat.
- Es war nicht langsam, weil das Modell schwach war.
- Es war langsam, weil du eine Linie gezeichnet hast, wo die Arbeit ein Graph war.
Dieser Leitfaden führt dich von dieser Linie zu einem Graphen, der sich über eine Flotte ausbreitet und seine eigene Arbeit überprüft.
Fünf Schritte. Ab Schritt 2 hast du einen gebaut -
Er gibt dir einen funktionierenden Graphen und nennt die Fallen, die echte Graphen zerstören, und ich zeige dir, wo die harten Teile beginnen.
vor dem Alpha - abonniere meinen Substack für mehr frisches Alpha ↓
Kapitel 0 - Was Graph Engineering eigentlich ist
Vor einem Monat sprach die Branche von Schleifen.
Peter Steinberger hat es in neun Worten eingefangen:
https://x.com/steipete/status/2078277297791189132
Eine Schleife ist ein Zyklus der Verbesserung:
etwas versuchen → das Ergebnis prüfen → anpassen → nochmal gehen
Das ist das Atom: ein einzelner Agent, der eine Sache wiederholt verbessert.
(Wenn du meinen Loop Engineering-Artikel gelesen hast, ist das genau das)
https://x.com/0xCodila/status/2072329149520232639
Aber die einzelne Schleife hat einen bekannten Fehler - ein Support-Team bindet eine Feedbackschleife an eine Metrik: Ticket-Lösungsrate
Die Zahl steigt monatelang, während die Zufriedenheit sinkt. Der Bot hat gelernt, Tickets schnell zu schließen, anstatt sie zu lösen.
Das ist Goodharts Gesetz. Eine Schleife kann nur ihre eigene Metrik sehen. Sie kann nicht fragen, ob das Ziel richtig ist, oder bemerken, dass ihre eigene Messung abdriftet.
Die Antwort ist keine bessere Schleife. Es ist ein Graph von Schleifen - ein Netzwerk, in dem Zyklen sich gegenseitig beobachten und korrigieren.
Für Agents bedeutet das eines:
Hör auf, einen Agenten zu schreiben, der alles in einer Linie macht - entwirf die
Form
der Arbeit - was läuft vor was, was läuft gleichzeitig, was wartet.
Knoten erledigen das Denken. Kanten tragen die Ergebnisse
Und Claude Code hat die Werkzeuge geliefert, um diese direkt zu bauen: dynamische Workflows
Schritt 1 - Erkenne die Kanten, die nicht da sind
Ein Graph hat zwei Teile:
- Ein Knoten ist eine Arbeitseinheit: ein Agent, ein Job, eine Eingabe, eine Ausgabe
- Eine Kante ist eine Abhängigkeit: Die Ausgabe dieses Knotens speist die Eingabe jenes Knotens.
Der Fehler, den jeder macht, ist, "und dann" als eine Kante zu behandeln.
"Fasse diese Datei zusammen
und dann
sage mir das Wetter"
Das Wetter liest die Zusammenfassung nicht.
Das sind zwei unabhängige Aufgaben, die ein lineares Skript grundlos verkettet. Jede wartet auf die letzte, ohne Grund.
Die Gewohnheit, die alles beginnt:
Frage bei jedem "und dann": Liest der nächste Schritt tatsächlich die Ausgabe des vorherigen Schritts?
- Wenn ja → echte Kante. Behalte die Reihenfolge.
- Wenn nein → keine Kante. Das Warten ist verschwendet. Lass sie parallel laufen.
Wenn keine Daten zwischen zwei Kästchen fließen, sind sie unabhängig.
Diese Unabhängigkeit nutzt du für den Rest dieses Leitfadens aus.
Dein einfacher "mach A, dann B, dann C"-Agent ist bereits ein Graph - nur der traurigste: eine einzelne Kette, in der, wenn C stockt, D nie passiert.
Schritt 2 - Baue deinen ersten Graphen (von Anfang bis Ende)
Genug Theorie. Baue einen und sieh ihn laufen.
Bevor du beginnst:
- Claude Code v2.1.154+ (überprüfe mit claude --version)
- Ein bezahlter Plan. Bei Max, Team oder Enterprise sind Workflows standardmäßig aktiviert. Bei Pro schalte die Dynamic Workflows-Zeile in /config ein.
1. Öffne ein Repository, das du kennst.
Ein echtes, damit das Ergebnis etwas bedeutet.
2. Füge diesen Prompt ein (von Anthropic):
1Erstelle einen Workflow, um jede Routen-Datei unter src/routes/2auf fehlende Auth-Prüfungen zu auditieren. Starte einen Agenten pro Datei und führe dann3einen unabhängigen Prüfer für jeden Fund aus, bevor du berichtest.4Analysiere zu Beginn maximal 20 Dateien.
Ersetze src/routes/ durch den Ort, an dem deine Dateien liegen. Die "max 20"-Zeile hält deinen ersten Durchlauf günstig.
3. Sieh zu, wie "Workflow" aufleuchtet.
Claude Code hebt es hervor: "Dynamic workflow requested." Das ist dein Signal, dass ein Graph gebaut wird, nicht ein normales Gespräch.
4. Genehmige den Plan.
Claude schreibt ein JavaScript-Orchestrierungsskript und zeigt zuerst die Phasen an. Lies sie, wähle "Ja, ausführen."
5. Lass die Flotte laufen.
Ein Agent pro Datei, parallel, während deine Sitzung frei bleibt.
Tippe /workflows, um es live zu sehen: Umfang, Aufteilung, Überprüfung, Synthese.
6. Lies die eine Antwort.
Nicht zwanzig separate Chats. Ein Bericht - weil die Zwischenergebnisse in den Variablen des Skripts lebten, nicht in deinem Kontext.
Das ist ein Graph.
Ein Dutzend Agents, aus einem einzigen Satz.
Über die Behauptung "null Tokens", die du hören wirst
Das Koordinationsskript ist Code.
Das Weitergeben von Ergebnissen zwischen Agents verbraucht also nicht erneut Kontext, wie es eine Chat-Übergabe tun würde.
Aber die Agents kosten trotzdem Nutzung. Ein Workflow kostet deutlich mehr als eine normale Sitzung.
Die Ersparnis liegt in der Koordination, nicht in der Arbeit. Beginne begrenzt, beobachte die Nutzung, dann erweitere.
- Mach es zu deinem
Wenn ein Durchlauf gut ist, drücke s.
Es wird unter ~/.claude/workflows gespeichert und kann erneut nach Namen ausgeführt werden.
Ändere jetzt die Aufgabe und behalte die Form. Ersetze "fehlende Auth-Prüfungen" durch "nicht behandelte Promises" oder "Funktionen über 100 Zeilen."
Wie weit das skaliert (Artikelname)
Ein einzelner Workflow-Durchlauf kann auf 1.000 Agents aufgeteilt werden, wobei bis zu 16 gleichzeitig arbeiten.
Daher kommt "1000+ Schleifen in einem Fenster" - keine Metapher, die tatsächliche Obergrenze der Funktion.
- Und die Skalierung ist der Punkt Eintausend Agents bedeuten einen Job, den kein einzelner Kontext jemals halten könnte - eine ganze Codebasis auf einmal auditiert, eine Migration, die jede Datei berührt, eine Suche, die tausend Blickwinkel parallel ausführt.
Das Limit von 16 gleichzeitig bedeutet nur, dass die Flotte in Wellen vorrückt und alle tausend durcharbeitet, ohne dass du einen einzigen beaufsichtigen musst.
Beginne mit 20, um zu sehen, wie ein Durchlauf sich verhält und was er kostet - dann öffne ihn - denn das ist die Obergrenze, gegen die sonst niemand baut.
Schritt 3 - Der Teil, der tatsächlich kaputt geht
Du hast einen Graphen gebaut. Hier ist, wo echte scheitern.
Zwei Fehler sind am wichtigsten
- Fehler eins: Der Graph stimmt sich selbst zu
Wenn ein Agent seine eigene Arbeit überprüft, geht er milde mit sich um. Modelle bevorzugen ihre eigenen Ausgaben.
Also setzt du einen Prüfer auf die Kante - einen separaten Knoten, der einen Fund bestätigt, bevor er downstream fließt.
Der Haken, den niemand nennt: Der Prüfer braucht einen sauberen Kontext
Gib ihm dasselbe Gespräch, das der Ausführende hatte, und er prüft nicht. Er stimmt sich selbst zu, nur in einer anderen Schriftart.
Ein Graph von Agents, die sich einen Kontext teilen, ist eine einzelne Schleife im Kostüm. Er versagt auf die gleiche Weise - später, teurer, mit mehr grünen Lichtern auf dem Weg nach unten.
Also ist der Prüfer ein neuer Knoten - Eigener Kontext - Prüft ein echtes Signal - nicht "hat der Agent gesagt, es ist fertig", sondern "besteht der Test tatsächlich"
- Fehler zwei: Agents treten sich gegenseitig auf die Füße
Das ist nicht hypothetisch
Als Buns Team zuerst einen großen Port auf viele Agents verteilte, scheiterte der Durchlauf operativ - Agents verwendeten gemeinsame Git-Befehle in einem Arbeitsbereich und überschrieben sich gegenseitig.
Die Lösung war strukturell, nicht ausgeklügeltes Prompting. Sie verboten die unsicheren Befehle und gaben jeder Gruppe ihren eigenen isolierten Worktree
Das ist die wahre Lektion der Parallelität - zwei Agents, die dieselbe Datei schreiben, geraten in Wettbewerb.
Bevor du aufteilst, beantworte drei Fragen:
- Wo arbeitet jeder Agent?
- Wie werden Ergebnisse zusammengeführt?
- Was passiert, wenn zwei sich uneinig sind?
Ein Graph ohne diesen Plan skaliert nicht - Er scheitert schneller.
Schritt 4 - Sechs Graphen, die du diese Woche bauen kannst
Die Methode: Finde die echten Kanten → teile auf → überprüfe in unabhängigem Kontext → isoliere die Arbeiter.
///
Jeder von diesen hat die gleiche Form, nur auf eine neue Aufgabe ausgerichtet. Ändere die Aufgabenzeile und los geht's:
- Sicherheitsscan - ein Agent pro Datei auf der Jagd nach fehlender Auth, ein Prüfer, der jeden Treffer bestätigt (der, den du gebaut hast).
- Zitierter Bericht mit /deep-research - existiert bereits: teilt deine Frage in Blickwinkel auf, sucht parallel, Agents widerlegen sich gegenseitig vor dem Schreiben.
- Ein Modul portieren - Datei für Datei, Tests als Tor, Fehlschläge werden zurückgeschleift.
- Adversariales Diff-Review - nach Größe geroutet: kleine Änderung → ein Durchgang; große → vollständiges paralleles Audit.
- Geplanter Ökosystem-Scan - einmal speichern, erneut nach Namen ausführen.
- Entdeckung unbekannter Größe - Sucher laufen parallel, jedes Ergebnis wird gegen alles Gesehene geprüft, Schleife, bis zwei Runden nichts Neues finden.
///
Wie die Obergrenze aussiehthttps://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Buns Zig-zu-Rust-Port lief auf genau dieser Maschinerie.
Etwa 50 Workflows, ein Maximum von 64 Agents parallel. Ungefähr 535.000 Zeilen Zig wurden in über eine Million Zeilen Rust umgewandelt, in 11 Tagen.
Es kostete auch etwa 165.000 US-Dollar an Nutzung. Es brauchte einen Menschen, der das Ganze entwarf und überwachte.
Und es zog öffentliche Kritik auf sich, ob so viel KI-gestützter Code sicher überprüft werden kann.
Die Skalierung ist real. Ebenso der Preis und die Aufsicht.
Schritt 5 - Die Anker, die einen Graphen ehrlich halten
Topologie allein kauft keine Wahrheit
Ein Netzwerk von Agents, die sich alle gegenseitig bestätigen, von denen keiner etwas Reales anfasst, scheitert genauso wie die einzelne Schleife - nur mit mehr beweglichen Teilen.
Der Graph braucht Anker: Knoten, mit denen man nicht argumentieren kann.
- Tests, die tatsächlich gelaufen sind - nicht "sollte bestehen", ist bestanden.
- Ein Prüfer auf Basis von Beweisen, nicht von Bauchgefühl
- Eingefrorene Regeln, die die Agents niemals optimieren dürfen - weil sie diejenigen sind, die ein Optimierer schwächen würde.
Der Graph ist nur so ehrlich wie die Dinge in ihm, die sich weigern, sich zu bewegen.
Wann ein Graph die falsche Wahl ist
Die meisten Aufgaben sind keine Graphen. Nach einem zu greifen, wenn du ihn nicht brauchst, verbrennt nur Geld und fügt Wege des Scheiterns hinzu.
Überspringe den Graphen, wenn:
- Die Aufgabe klein oder isoliert ist. Eine Funktion hinzufügen, einen Fehler beheben. Ein Workflow ist hier reiner Overhead - ein einzelner Agent ist schneller und billiger.
- Du eine enge Aufsicht brauchst. Wenn du jeden Schritt lesen und genehmigen willst, bevor der nächste läuft, arbeitet der ganze Sinn eines Graphen (breit zu laufen ohne dich) gegen dich.
- Du noch nicht weißt, wonach du suchst. Erkundungsarbeit will einen Agenten, den du steuern kannst, nicht eine Flotte, die auf einen Plan festgelegt ist, bevor du das Problem verstehst.
- Die Schritte tatsächlich voneinander abhängen. Wenn jeder Schritt die Ausgabe des letzten Schritts liest, ist es eine echte Kette. Parallelität hat nichts zu greifen. Das Erzwingen eines Graphen für eine wirklich sequentielle Aufgabe fügt nur Koordinationskosten für null Geschwindigkeitsgewinn hinzu.
Der Hinweis ist Schritt 1. Wenn du nicht zwei Kästchen ohne Pfeil dazwischen finden kannst, gibt es keinen Graphen zu bauen. Es ist eine Schleife, und eine Schleife ist in Ordnung.
Ein Graph ist ein Werkzeug für Breite - unabhängige Arbeit, die auf einmal erledigt wird.
Wenn die Arbeit nicht breit ist, war die Linie nie das Problem...
Der Wandel
Ein Prompter stellt eine Frage. Ein Architekt zeichnet einen Graphen.
Der lineare Agent war nie die Obergrenze.
Er war die erste Form - die, nach der jeder greift, weil sie zu unserem Tippen passt: eine Linie, eine Sache nach der anderen.
Sobald du die Knoten und Kanten siehst, hörst du auf, den Agenten zu bitten, mehr zu tun, und fängst an, den Graphen zu bitten, es breiter zu machen:
- Teile auf, wo die Arbeit unabhängig ist
- Verschließe die Kanten, wo Vertrauen zählt
- Friere die Knoten ein, die die Wahrheit halten
Die meisten Leute werden weiterhin Schritte in einer Linie anordnen.
Die wenigen, die lernen, den Graphen zu zeichnen und zu respektieren, was ihn zerbricht, werden eine Flotte betreiben.
Zeichne den Graphen. Bleib der Architekt.
Beginne mit der Voraussetzung:
- die einzelne Schleife, auf der dies aufbaut
