Der 14-Schritte-Fahrplan:
Von Prompts zu einer Flotte von Agenten, die für Sie arbeitet

Schritt eins, danach Schritt zwei, anschließend Schritt drei. Jeder Schritt wartet brav darauf, dass der vorherige vollständig beendet ist, bevor er selbst loslegt.

Dabei übersehen fast alle, dass ungefähr die Hälfte dieser Schritte überhaupt keine Abhängigkeit voneinander hat und deshalb gar nicht warten müsste.

Sie routen nichts. Sie verzweigen nichts. Sie arbeiten nichts parallel ab. Sie reihen lediglich Aufgaben aneinander. Ein Kopf, ein Kontext, eine Aufgabe nach der anderen - bis das Kontextfenster voll ist und der Agent nicht mehr weiß, woran er ursprünglich gearbeitet hat.

Der folgende Fahrplan mit 14 Schritten verwandelt diese lineare Schlange in einen Graphen. Dieser Graph kann sich auf eine komplette Flotte von Agenten auffächern, die eigenen Ergebnisse überprüfen und anschließend zu einem Resultat zusammenlaufen, das ein einzelner Agent niemals alleine zuverlässig bewältigen könnte.

Nach Abschluss dieses Fahrplans kennen Sie drei Dinge:

• → an welchen Stellen Ihr derzeitiges System unnötig wartet
• → wie Sie Arbeit verteilen können, ohne das Vertrauen in die Ergebnisse zu verlieren
• → wie Sie die Kosten reduzieren, ohne die Qualität zu verschlechtern

Der Perspektivwechsel, den Ihnen niemand erklärt

Ein Prompt ist eine einzelne Anweisung. Ein Loop ist ein wiederholter Ablauf. Ein Harness ist die Grundlage, auf der Ihr Agent arbeitet.

Doch die eigentliche Struktur der Arbeit - also welche Aufgabe vor welcher ausgeführt wird, welche Aufgaben gleichzeitig laufen dürfen und welche erst beginnen können, wenn andere fertig sind - ist ein Graph.

Die Knoten übernehmen das Denken. Die Kanten transportieren die Ergebnisse.

Claude Code verfügt bereits über das notwendige Werkzeug, um solche Strukturen direkt aufzubauen: dynamische Workflows.

Claude erstellt ein Orchestrierungsskript in normalem JavaScript und startet damit anschließend eine koordinierte Flotte von Subagenten. Die Koordination verursacht dabei keine Modell-Tokens, weil sie durch Code und nicht durch eine zusätzliche Unterhaltung mit dem Modell erfolgt.

Der Fahrplan gliedert sich in vier Bereiche:

• → 01 bis 04: Erkennen, welchen Graphen Sie bereits besitzen
• → 05 bis 08: Die Agentenflotte tatsächlich einsetzen
• → 09 bis 11: Vertrauen in die erzeugten Ergebnisse schaffen
• → 12 bis 14: Verhindern, dass die Kosten aus dem Ruder laufen

Block 1 · Den bereits vorhandenen Graphen erkennen

01. Knoten sind Aufgaben, Kanten sind die Daten, die fließen

Ein Graph besteht im Wesentlichen aus zwei Bestandteilen. Wenn Sie diese sauber auseinanderhalten, verschwinden viele typische Missverständnisse.

• → Knoten: Eine einzelne Arbeitseinheit. Das kann ein Agent, eine klar begrenzte Aufgabe oder eine definierte Eingabe mit einer definierten Ausgabe sein.
• → Kante: Eine Abhängigkeit zwischen zwei Knoten. Sie bedeutet, dass die Ausgabe des einen Knotens als Eingabe für einen anderen Knoten dient. Mehr steckt nicht dahinter.

Der typische Denkfehler besteht darin, jedes „und danach" automatisch als Kante zu betrachten.

Nehmen Sie beispielsweise die Anweisung: „Fasse diese Datei zusammen und sage mir danach, wie das Wetter ist."

Zwischen diesen beiden Tätigkeiten gibt es keine echte Kante. Die Wetterinformation benötigt die Zusammenfassung überhaupt nicht. Es handelt sich um zwei unabhängige Knoten, die lediglich deshalb nacheinander ausgeführt werden, weil ein lineares Skript sie in dieser Reihenfolge miteinander verbindet.

Eine Kante existiert nur dann wirklich, wenn Daten tatsächlich von einem Knoten zum nächsten übertragen werden.

Stellen Sie sich den Graphen deshalb als Kästen mit Pfeilen dazwischen vor. Jeder Kasten entspricht einem Aufruf von agent(). Jeder Pfeil entspricht einer Variable, die aus dem return eines Aufrufs kommt und anschließend in den Prompt eines anderen Aufrufs gelangt.

Wenn Sie einen solchen Pfeil nicht zeichnen können - wenn also keine Variable zwischen den beiden Knoten übertragen wird -, sind die beiden Kästen unabhängig.

Genau diese Unabhängigkeit ist der wichtigste Hebel für die nächsten 13 Schritte.

→ Die Regel: Bei jedem „und dann" müssen Sie prüfen, ob der folgende Schritt tatsächlich die Ausgabe des vorherigen verwendet. Falls nicht, verschwenden Sie durch das Warten lediglich Zeit.

02. Ihr linearer Ablauf ist schon ein Graph - nur in seiner einfachsten Form

Wenn Sie einen Agenten nach dem Muster „erst A, dann B, dann C und danach D" definieren, haben Sie bereits einen Graphen erstellt.

Es handelt sich dabei lediglich um eine Kette ohne Verzweigungen. Jeder Knoten besitzt genau eine eingehende und eine ausgehende Kante.

Das funktioniert grundsätzlich. Gleichzeitig ist es langsam und anfällig, weil eine solche Kette keinerlei Redundanz besitzt. Wenn C stecken bleibt, wird D niemals ausgeführt. Die Arbeit von A bleibt dadurch weiter oben im Ablauf hängen und kann nicht weiterfließen.

Die erste zentrale Fähigkeit des Graph Engineering besteht deshalb darin, diese Kette neu zu zeichnen.

Nehmen Sie Ihren linearen Agenten und überprüfen Sie jeden einzelnen Pfeil anhand der Frage aus Schritt 01.

Bei den meisten linearen Abläufen finden Sie zwei oder drei Verbindungen, über die überhaupt keine Daten transportiert werden. Diese existieren lediglich deshalb, weil Sie die Aufgaben in genau dieser Reihenfolge programmiert haben.

Wenn Sie diese unnötigen Verbindungen entfernen, zerfällt die Kette in eine breitere Struktur: Mehrere voneinander unabhängige Knoten können gleichzeitig arbeiten und anschließend ihre Ergebnisse an einen einzelnen Knoten weitergeben, der tatsächlich alle Ergebnisse benötigt.

Dafür brauchen Sie weder zusätzliches Geld noch ein neues Werkzeug. In vielen Fällen entfernen Sie dadurch mehr Wartezeit als durch jede zusätzliche technische Anschaffung.

→ Die Regel: Bevor Sie neue Komponenten einbauen, entfernen Sie zuerst alle Kanten, über die keine Daten fließen.

03. Geben Sie jedem Knoten einen klaren Vertrag

Ein Knoten, dessen Verhalten und Ein- und Ausgabe nicht klar definiert sind, lässt sich nur schwer zuverlässig parallelisieren.

Die Lösung ist ein klarer Vertrag: eine begrenzte Eingabe, eine begrenzte Ausgabe und genau eine Aufgabe.

• → Die Eingabe muss explizit festlegen, welche Informationen der Knoten verarbeitet. Sie darf nicht stillschweigend aus einem gemeinsamen Kontextfenster vorausgesetzt werden.
• → Die Ausgabe muss eine festgelegte Form besitzen, idealerweise zusätzlich validiert, damit der nachfolgende Knoten sie direkt verwenden kann, ohne interpretieren oder raten zu müssen.

In einem Workflow wird dieser Vertrag über ein Schema festgelegt. Übergeben Sie Claude bei einem agent()-Aufruf ein JSON-Schema, muss der Subagent eine gültige strukturierte Ausgabe liefern.

Die Validierung findet auf Ebene des Tool-Aufrufs statt. Wenn die Ausgabe nicht dem erwarteten Schema entspricht, kann erneut versucht werden, statt dass Sie zunächst freien Text bekommen, den Sie anschließend selbst parsen und auf korrekte Struktur prüfen müssen.

// ein Knoten mit echtem Vertrag: begrenzte Eingabe,
// validierte Ausgabe, eine einzige Aufgabe
const ELEMENT = {
  type: 'object',
  additionalProperties: false,
  properties: {
    titel:   { type: 'string' },
    url:     { type: 'string' },
    wirkung: { type: 'string', enum: ['hoch', 'mittel', 'gering'] },
  },
  required: ['titel', 'url', 'wirkung'],
};

const ausgabe = await agent(quelle.prompt, {
  label: `research:${quelle.key}`,
  schema: ELEMENT,
  agentType: 'general-purpose',
});

Genau das unterscheidet einen Knoten, den Claude sauber in einen Graphen integrieren kann, von einem bloßen Gespräch, dessen Ergebnis erst von einem Menschen interpretiert werden muss.

→ Die Regel: Besitzt die Ausgabe eines Knotens keine definierte Form, handelt es sich nicht wirklich um einen Knoten, sondern um eine Unterhaltung.

04. Auch die Kante hat einen Vertrag - und sie kostet nichts

Eine Kante bedeutet nicht einfach „B wird nach A ausgeführt".

Sie beschreibt vielmehr eine Zusicherung darüber, welche Daten übertragen werden: A erzeugt eine bestimmte Form von Daten und B ist darauf ausgelegt, genau diese Form zu verarbeiten.

Wenn Sie eine Kante nach den transportierten Daten statt nach ihrer Reihenfolge benennst, werden zwei Dinge unmittelbar einfacher:

• → Sie erkennen sofort, ob die Kante überhaupt real ist, weil Sie prüfen können, ob tatsächlich Daten darüber übertragen werden.
• → Sie können den Knoten an einem der beiden Enden austauschen, ohne den Graphen zu beschädigen, solange die Datenform unverändert bleibt.

Praktisch wird eine solche Kante durch normales JavaScript umgesetzt.

Die Reduktion zwischen Fan-out und Synthese - also beispielsweise Flattening, Deduplizierung oder Filtern - ist lediglich Code, der auf den Datenformen arbeitet, die Ihre Knoten geliefert haben.

Dafür ist kein Agent erforderlich.

Das ist einer der eher unscheinbaren Vorteile des graphbasierten Denkens: Ein erstaunlich großer Teil dessen, wofür Menschen Modell-Tokens ausgeben, besteht eigentlich nur aus Kanten. Und Kanten kosten keine Tokens.

Die Versuchung besteht darin, einen Agenten zu starten, der „die Ergebnisse zusammenführt".

Das sollten Sie vermeiden.

Wenn „Zusammenführen" lediglich bedeutet, eine Liste zu flatten und Duplikate zu entfernen, reichen ein flatMap und ein Set. Das ist deterministisch, sofort erledigt und benötigt keine Tokens.

→ Die Regel: Agenten sind für Entscheidungen und Urteilsvermögen gedacht, nicht für einfache Datenverarbeitung. Wenn jede Kante durch einen Agenten realisiert wird, bezahlen Sie einen Agenten für die eigene Verkabelung.

Block 2 · Die Flotte in Bewegung bringen

KI-generiert

KI-generiert

05. Mit parallel() auseinanderfächern

Dieser Schritt ist die Grundlage für fast alles, was danach kommt.

Wenn Sie N unabhängige Knoten haben - N Quellen, die Sie abfragen möchten, N Dateien, die Sie prüfen müssen, oder N Pfade, die Sie auditieren wollen -, sollten Sie sie nicht nacheinander ausführen.

Stattdessen lassen Sie Claude die Aufgaben auffächern und gleichzeitig ausführen.

In einem Workflow übernimmt parallel() diese Aufgabe. Es erhält ein Array von Thunks, startet für jeden davon einen Subagenten, führt sie gleichzeitig aus und gibt anschließend ein Array mit den Ergebnissen zurück.

Zwei Eigenschaften machen dieses Vorgehen besonders robust:

• → parallel() bildet eine Barriere. Erst wenn alle Thunks abgeschlossen sind, wird das Ergebnis zurückgegeben. Die nächste Phase erhält dadurch die komplette Ergebnismenge.
• → Wenn ein einzelner Thunk eine Exception verursacht, wird dessen Ergebnis zu null, anstatt den gesamten Batch zu stoppen. Ein einzelner instabiler Agent kann somit nicht die komplette Ausführung zerstören.

Deshalb sollte auf das Ergebnis anschließend immer .filter(Boolean) angewendet werden.

Die mögliche Parallelität ist ungefähr durch die Anzahl der verfügbaren Kerne begrenzt. Alles darüber wird gewissermaßen in Gruppen abgearbeitet. Sie können daher beispielsweise hundert Thunks übergeben; sie werden letztlich alle abgeschlossen, nur eben nicht zwingend alle gleichzeitig.

phase('Research');

const roh = await parallel(
  QUELLEN.map((q) => () =>
    agent(q.prompt, {
      label: `research:${q.key}`,
      phase: 'Research',
      schema: ELEMENT,
      agentType: 'general-purpose',
    }),
  ),
);

const gesammelt = roh.filter(Boolean);   // null-Werte gefallener Agenten entfernen

Entscheidend ist dabei, dass der Fan-out durch Code realisiert wird, den Claude geschrieben hat - nicht durch eine lange Unterhaltung mit dem Modell.

Claude selbst muss niemals alle neun Quellen gleichzeitig in seinem eigenen Kontext halten.

Jeder Subagent lädt und bearbeitet seine eigene Quelle und liefert anschließend nur das relevante Endergebnis zurück.

Dadurch lässt sich das System auf Dutzende oder sogar Hunderte von Subagenten erweitern, ohne die eigentliche Sitzung mit sämtlichen Kontexten zu überladen.

Die Orchestrierung verursacht keine zusätzlichen Tokens, weil sie nicht aus einem weiteren Denkturn von Claude besteht, sondern aus ausführbarem Code.

→ Die Regel: Wenn N Aufgaben nicht voneinander abhängig sind und die Ergebnisse der jeweils anderen nicht benötigen, stellen Sie sie nicht hintereinander. Fächern Sie sie auf.

06. Schließen Sie den Fan-out mit einer Barriere

Ein Fan-out bringt nur dann etwas, wenn anschließend auch etwas mit den verteilten Ergebnissen geschieht.

Der Fan-in ist der Punkt, an dem die verschiedenen Kanten wieder zusammenlaufen.

Dort kann entweder ein Agent oder normaler Code gleichzeitig auf sämtliche Ergebnisse zugreifen und eine Aufgabe durchführen, die tatsächlich die vollständige Menge benötigt.

Dazu gehören beispielsweise das Entfernen von Duplikaten über mehrere Quellen hinweg, das Sortieren nach Auswirkung oder ein vorzeitiger Abbruch, wenn überhaupt kein Ergebnis vorhanden ist.

Genau an dieser Stelle kann sich eine Barriere hinsichtlich der tatsächlichen Laufzeit lohnen.

Wenn Sie über alle Quellen hinweg deduplizieren müssen, ist eine Barriere sinnvoll.

Wenn Sie dagegen lediglich eine Liste flatten müssen, ist das nur eine Kante und sollte direkt im Code erledigt werden.

// die Kante: einfaches JS, kein Agent, null Tokens
const flach = gesammelt.flatMap((q) => q.items);
log(`${flach.length} Elemente gesammelt`);

phase('Kuratieren');

// der Barriereknoten: benötigt die GESAMTE Menge,
// um Duplikate zu entfernen und zu sortieren
const kuratiert = await agent(
  `Entferne Duplikate und sortiere nach Wirkung:\n${JSON.stringify(flach)}`,
  { phase: 'Kuratieren', schema: KURATIERT },
);

Ein einfacher Test hilft:

Wenn Ihr Ablauf „parallel → transformieren → parallel" lautet und die Transformation zwischen den beiden parallelen Phasen keine Abhängigkeit zwischen den einzelnen Elementen besitzt, hätten Sie stattdessen eine Pipeline verwenden können und die Barriere komplett vermieden.

→ Die Regel: Eine Barriere darf nur dort eingesetzt werden, wo die nächste Phase tatsächlich alle vorherigen Ergebnisse gleichzeitig benötigt.

07. Der Diamant: aufteilen, bearbeiten, zusammenführen

Wenn Sie Fan-out und Fan-in kombinieren, erhalten Sie die grundlegende Topologie für ernsthafte Agenten-Graphen: den Diamanten.

Ein Knoten zerlegt die Aufgabe. Viele Knoten bearbeiten die einzelnen Teile parallel. Danach führt ein weiterer Knoten die Ergebnisse wieder zusammen.

Das typische Muster lautet:

Fan-out → Reduce → Synthese

• → Fan-out schafft Breite
• → Reduce komprimiert diese Breite mit einfachem Code
• → Die Synthese wird von einem finalen Agenten durchgeführt, der die eigentliche Antwort formuliert

Dieses Grundgerüst lässt sich für Marktanalysen, Dependency-Audits, Code-Reviews oder Research-Berichte verwenden.

Die Quellen und Prompts können ausgetauscht werden, während die grundsätzliche Struktur gleich bleibt.

Sobald Sie beginnen, den Diamanten zu erkennen, verändert sich auch die zentrale Frage.

Sie fragen nicht mehr:

„Wie kann ich meinen Agenten dazu bringen, noch mehr Schritte auszuführen?"

Sondern:

„Wo wird die Aufgabe aufgeteilt und wo werden die Ergebnisse wieder zusammengeführt?"

Das ist die Frage, die für Skalierung entscheidend ist.

→ Die Regel: Planen Sie nicht primär einzelne Schritte. Planen Sie die Stellen, an denen die Arbeit auseinandergeht und wieder zusammenkommt.

08. Routen Sie die Kante während der Ausführung

Nicht jeder Graph muss statisch sein.

Manchmal hängt der weitere Ablauf davon ab, was ein vorheriger Knoten entdeckt hat.

Ein Router-Knoten betrachtet ein Ergebnis und entscheidet, welcher Pfad anschließend ausgeführt werden soll.

Beispielsweise kann ein Ticket klassifiziert und anschließend an den passenden Handler weitergeleitet werden. Oder die Größe eines Diffs entscheidet darüber, ob nur eine schnelle Prüfung oder ein vollständiges Audit durchgeführt wird.

In einem Workflow kann diese Entscheidung schlicht durch ein JavaScript-if oder switch auf Basis der validierten Ausgabe eines Knotens umgesetzt werden, weil die eigentliche Ablaufsteuerung im Code liegt.

// Router-Knoten: Ein Agent klassifiziert,
// der Code wählt die Kante
const { schweregrad } = await agent(
  `Klassifiziere das Risiko dieses Diffs:\n${diff}`,
  { schema: {
      type: 'object',
      properties: { schweregrad: { enum: ['niedrig', 'hoch'] } },
      required: ['schweregrad'],
  }},
);

let pruefung;
if (schweregrad === 'hoch') {
  pruefung = await parallel(DATEIEN.map((d) => () => agent(`Auditiere ${d}`)));
} else {
  pruefung = await agent(`Schnelle Prüfung von ${diff}`);
}

Hier ist Determinismus kein Nachteil, sondern ausdrücklich ein Vorteil.

Das Modell kann die Klassifizierung übernehmen, aber die eigentliche Weiterleitung wird vom Code kontrolliert.

Bei derselben Klassifizierung verhält sich der Router daher jedes Mal gleich.

Das Modell liefert das Urteil im Knoten; das Skript sorgt für zuverlässiges Verhalten auf der Kante.

Dadurch entstehen keine unerwarteten Entscheidungen wie „der Agent hat sich dazu entschlossen, das Audit zu überspringen". Ein solcher Sprung müsste explizit im Graphen programmiert sein - und das ist er nicht.

→ Die Regel: Lassen Sie das Modell bestimmen, was etwas ist, und überlassen Sie dem Code die Entscheidung darüber, was anschließend damit geschieht.

Die Gegenregel - vor dem Weiterlesen

Ein Graph verschafft Ihnen Breite.

Er verschafft Ihnen nicht automatisch besseres Urteilsvermögen.

Wenn jeder Arbeitsschritt das vollständige Ergebnis des vorherigen Schrittes benötigt, bringt die Aufteilung auf mehrere Agenten keine bessere Antwort.

Sie erhalten im Wesentlichen dieselbe Antwort - nur später und zu höheren Kosten.

Ein Graph wird genau dann interessant, wenn sich die Arbeit in einzelne Aufgaben zerlegen lässt, die die Ergebnisse der jeweils anderen nicht lesen müssen.

Bevor Sie auch nur einen weiteren Agenten hinzufügen, gibt es deshalb eine entscheidende Frage für Ihre Kosten:

Wo kann ich meine Arbeit aufteilen?

Wenn es keine solche Aufteilung gibt, sollten Sie bei einem einzelnen Agenten bleiben und sich die sechs folgenden Schritte sparen.

Block 3 · Vertrauen in die Ergebnisse aufbauen

KI-generiert

KI-generiert

09. Setzen Sie einen Verifizierer auf die Kante

Der wichtigste Vorteil eines Graphen besteht nicht einfach darin, mehr Agenten zu besitzen.

Der wirkliche Hebel entsteht durch die Struktur, die Sie um diese Agenten herum aufbauen, um zuverlässigere Ergebnisse zu erhalten.

Ein Verifizierer-Knoten sitzt auf einer Kante, bevor ein Ergebnis weitergegeben werden darf.

Seine Aufgabe besteht ausschließlich darin, den Fund zu widerlegen.

Wenn der Fund die Prüfung übersteht, darf er weiterfließen. Wenn er scheitert, gelangt er überhaupt nicht bis zum finalen Ergebnis.

Dabei gilt eine besonders wichtige Regel:

Ein Agent sollte niemals seine eigene Prüfung korrigieren.

Ein Modell, das seine eigene Ausgabe kontrolliert, erkennt viele seiner eigenen Fehler nicht, weil es denselben Blickwinkel verwendet, aus dem bereits der ursprüngliche Fehler entstanden ist.

Drei Verifikationsmuster sind besonders nützlich:

• → Adversarische Verifizierung: Für jeden Fund werden N unabhängige Skeptiker gestartet, deren Aufgabe darin besteht, den Fund zu widerlegen. Nur wenn er die Mehrheit dieser Prüfungen übersteht, bleibt er bestehen.
• → Verifizierung mit unterschiedlichen Perspektiven: Jeder Prüfer bekommt einen anderen Blickwinkel. Beispielsweise Korrektheit, Sicherheit oder Reproduzierbarkeit. Diese unterschiedlichen Perspektiven finden Fehlerarten, die bei identischen Prüfungen unentdeckt bleiben würden.
• → Jury-Panel: Mehrere Lösungsversuche werden aus unterschiedlichen Perspektiven erzeugt. Juroren bewerten sie parallel. Anschließend wird das Ergebnis aus dem Gewinner und den besten Elementen der knapp unterlegenen Varianten synthetisiert.

Dieses Muster findet sich hinter besonders ambitionierten Agentenprojekten, beispielsweise beim Portieren einer vollständigen Runtime, bei der adversarische Prüfung direkt in den eigentlichen Loop eingebaut wird und nicht erst ganz am Ende stattfindet.

→ Die Regel: Kein Fund darf ohne Verifizierung weiterwandern. Außerdem sollten zwei Verifizierer niemals dieselbe Frage stellen.

10. Isolieren Sie die Knoten, damit ein Fehler nicht den ganzen Graphen infiziert

In einer linearen Kette kann ein einzelner Fehler den gesamten Ablauf blockieren.

Wenn C ausfällt, läuft D nicht mehr und die gesamte Kette kommt zum Stillstand.

In einem Graphen sollte ein Fehler dagegen möglichst auf den jeweiligen Knoten begrenzt bleiben.

Ein Teil dieser Isolation ist bereits eingebaut: Wenn ein Thunk innerhalb von parallel() abstürzt, wird er zu null.

Die übrigen acht Agenten können also trotzdem erfolgreich arbeiten, während der fehlerhafte Agent lediglich selbst ausfällt.

Das anschließende .filter(Boolean) übernimmt dabei die Rolle der Fehlerbegrenzung.

Auch die Fan-ins sollten so gestaltet sein, dass sie fehlende Ergebnisse tolerieren, statt immer davon auszugehen, dass die vollständige Ergebnismenge vorhanden ist.

Eine subtilere Fehlerquelle entsteht, wenn mehrere Knoten gleichzeitig dieselben Dateien verändern.

Wenn mehrere Agenten parallel in Dateien schreiben, können sie miteinander kollidieren.

Die Lösung ist Isolation:

Jeder Agent arbeitet in einem eigenen Git-Worktree, erledigt seine Aufgabe in einer Sandbox und wird danach sauber zusammengeführt.

Das sollte allerdings nur dann eingesetzt werden, wenn tatsächlich mehrere Knoten gleichzeitig schreiben.

Es ist ein Sicherheitsmechanismus für genau die Topologie, die ihn benötigt, und keine zusätzliche Belastung, die standardmäßig bei jeder Ausführung entstehen sollte.

→ Die Regel: Pro Datei sollte es immer nur einen Schreiber geben. Und jeder Fan-in muss mit fehlenden Ergebnissen umgehen können.

11. Fügen Sie einen Loop hinzu - aber einen, der zum Ende kommt

Manchmal ist die Größe einer Aufgabe am Anfang nicht bekannt.

Das kann bei einer Entdeckung mit unbekanntem Umfang passieren oder bei einem Bug-Scan, bei dem ein gefundener Fehler weitere drei Fehler sichtbar macht.

Hier kann ein Loop sinnvoll sein: Eine kontrollierte Kante führt zurück zu einem früheren Knoten.

Das Risiko ist allerdings offensichtlich.

Ein Loop ohne Konvergenz kann zu einer Endlosschleife werden, in der immer neue Agenten gestartet werden, bis das Budget vollständig aufgebraucht ist.

Ein funktionierendes Muster ist deshalb „loop until dry".

Dabei werden weiterhin Suchagenten gestartet, bis K aufeinanderfolgende Runden keine neuen Ergebnisse mehr liefern. Erst dann wird der Loop beendet.

Ein besonders wichtiger Punkt entscheidet darüber, ob dieses Muster funktioniert:

Wogegen wird dedupliziert?

Die Deduplizierung muss gegen alles bisher Gesehene erfolgen und nicht nur gegen die bereits bestätigten Ergebnisse.

Andernfalls können abgelehnte Ergebnisse in jeder weiteren Runde erneut auftauchen. Der Loop würde niemals „trocken" werden und das System würde immer wieder Tokens dafür ausgeben, dieselben Sackgassen neu zu untersuchen.

const gesehen = new Set();
const bestaetigt = [];
let leer = 0;

while (leer < 2) {                             // nach 2 leeren Runden stoppen
  const gefunden = (await parallel(
    SUCHER.map((s) => () => agent(s.prompt, { schema: BUGS }))
  )).filter(Boolean).flatMap((r) => r.bugs);

  const neue = gefunden.filter((b) => !gesehen.has(schluessel(b)));
  if (!neue.length) { leer++; continue; }       // nichts Neues → wird trocken

  leer = 0;
  neue.forEach((b) => gesehen.add(schluessel(b)));  // gegen GESEHENE deduplizieren,
                                                   // nicht gegen bestätigte

  const beurteilt = await parallel(neue.map((b) =>
    parallel(['korrektheit', 'sicherheit', 'repro'].map((linse) =>
      agent(`Beurteile "${b.desc}" aus Sicht ${linse}. Ist das real?`, { schema: URTEIL })))
      .then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))
  ));

  bestaetigt.push(...beurteilt.filter((v) => v.real).map((v) => v.b));
}

→ Die Regel: Jeder Loop braucht eine maximale Zahl von Runden und muss gegen sämtliche bereits gesehenen Ergebnisse deduplizieren.

Block 4 · Verhindern, dass die Kosten explodieren

12. Verwenden Sie nicht für jeden Knoten dasselbe Modell

Nicht jeder Knoten braucht das leistungsfähigste Modell.

Ein Graph macht diesen Unterschied besonders deutlich.

Einige Knoten erledigen klar begrenzte, repetitive Aufgaben wie das Extrahieren eines bestimmten Feldes oder das Klassifizieren eines Tickets.

Andere Knoten übernehmen die Aufgaben, bei denen echtes Urteilsvermögen erforderlich ist: einen Bericht synthetisieren oder einen Fund bewerten.

Die einfachen Aufgaben können Sie mit einem günstigeren Modell durchführen und die teuren Tokens dort einsetzen, wo tatsächlich Entscheidungskompetenz benötigt wird.

Innerhalb eines Workflows übernimmt ein Subagent standardmäßig das Modell Ihrer Sitzung, sofern das Skript dieses Verhalten nicht überschreibt.

Eine größere Ausführung wird dadurch standardmäßig auf Ihrem aktuellen Sitzungsniveau abgerechnet.

Mit der Option model in einem konkreten agent()-Aufruf können Sie dagegen gezielt nur diesen einzelnen Knoten an ein anderes Modell weiterleiten.

Vor einer größeren Ausführung sollten Sie /model überprüfen.

Anschließend können Sie die repetitiven Knoten innerhalb des Fan-outs auf ein günstigeres Modell umstellen und das leistungsfähigere Modell für den Fusionsknoten beibehalten.

Damit lässt sich ein stark tokenverbrauchender Graph günstiger machen, ohne seine grundlegende Struktur zu verändern.

→ Die Regel: Setzen Sie ein teures Modell nur dort ein, wo tatsächlich Urteilsvermögen erforderlich ist.

13. Die Topologie bestimmt Kosten und Laufzeit

Die Form Ihres Graphen ist keineswegs nur eine Frage der Darstellung.

Sie gehört zu den wichtigsten Faktoren für die tatsächliche Laufzeit.

Eine besonders häufige Fehlentscheidung betrifft die Wahl zwischen:

parallel() und pipeline()

• → Eine parallel()-Barriere zwingt die nächste Phase dazu, auf das langsamste Element zu warten. Erst wenn alle vorherigen Aufgaben abgeschlossen sind, darf die nächste Stufe beginnen.
• → Bei pipeline() fließt dagegen jedes einzelne Element unabhängig durch die verschiedenen Phasen. Ein Element A kann bereits Phase 3 erreicht haben, während Element B noch in Phase 1 arbeitet.

Schnelle Elemente können dadurch früh fertig werden, anstatt hinter langsamen Elementen warten zu müssen.

Deshalb sollte grundsätzlich Pipeline der Standard sein.

Eine Barriere ist nur dann sinnvoll, wenn eine nachfolgende Phase tatsächlich die komplette Ergebnismenge gleichzeitig benötigt.

Beispiele dafür sind eine Deduplizierung über die gesamte Menge, eine Entscheidung über einen vorzeitigen Abbruch anhand der Gesamtmenge oder ein Prompt, der einen Fund ausdrücklich mit „den anderen Funden" vergleichen muss.

Argumente wie „es ist übersichtlicher" oder „die Phasen wirken dadurch sauber getrennt" reichen nicht aus.

Die durch eine Barriere verursachte Latenz ist reale, messbare und vermeidbare Wartezeit.

Trennung bedeutet nicht automatisch Synchronisierung.

→ Die Regel: Verwenden Sie standardmäßig eine Pipeline und nur bei einer konkret begründeten Notwendigkeit eine Barriere.

14. Lassen Sie Claude den Graphen selbst erstellen

Der letzte Schritt besteht darin, bei Aufgaben, deren genaue Struktur sich vorher nicht bestimmen lässt, nicht mehr selbst jeden Graphen zu entwerfen.

Mit dynamischen Workflows beschreiben Sie lediglich das gewünschte Ziel.

Claude erstellt daraufhin selbst das Orchestrierungsskript: Es zerlegt die Aufgabe, bestimmt den Fan-out, startet eine koordinierte Gruppe von Subagenten und führt die Ergebnisse anschließend zu einer Synthese zusammen.

Damit entsteht für die jeweilige Ausführung ein maßgeschneiderter Graph anstelle eines festen Graphen, von dem Sie vorher hoffen, dass er auf die konkrete Aufgabe passt.

Es gibt drei Möglichkeiten, einen solchen Workflow zu starten:

• → Schreiben Sie das Wort „workflow" in Ihren Prompt und Claude erstellt einen passenden Workflow für die Aufgabe.
• → Führen Sie einen bereits gespeicherten oder mitgelieferten Workflow aus. /deep-research ist beispielsweise ein realer Graph, der produktiv ausgeführt wird: Eingrenzen → parallele Suche → Fetch → adversarische Verifizierung → Synthese. Das entspricht exakt dem Grundgerüst dieses Fahrplans.
• → Aktivieren Sie den Modus, der für jede umfangreiche Aufgabe innerhalb der Sitzung automatisch einen Workflow plant.

Wenn eine Ausführung besonders gut funktioniert hat, können Sie das entsprechende Skript unter .claude/workflows/ speichern.

Es ist dann versioniert, kann erneut über seinen Namen ausgeführt werden und steht jedem zur Verfügung, der das Repository klont.

Beispiel:

Starte einen Workflow, der sämtliche Pfade unter src/routes/ überprüft und nach fehlender Authentifizierung sucht. Verwende einen Agenten pro Route-Datei und verifiziere jeden Fund, bevor er gemeldet wird.

Claude erzeugt anschließend ein Orchestrierungsskript und startet es im Hintergrund:

/workflows - auth-audit · running
✓ Eingrenzen      1/1     2.1k tok · 4s
✓ Fan-out         18/18   ein Agent pro Route-Datei
◯ Verifizieren    11/18   Skeptiker mit 3 Stimmen pro Fund …
○ Synthese         0/1    wartet auf Verifizierung

Während die Flotte arbeitet, bleibt die eigentliche Sitzung weiterhin verfügbar. Sie können also parallel weiterarbeiten.

→ Die Regel: Wenn sich die Struktur der Aufgabe bei jeder Ausführung verändert, sollten Sie den Graphen nicht selbst zeichnen. Beschreiben Sie stattdessen einfach die gewünschte Aufgabe.

Sechs Graphen, die Sie diese Woche bauen können

1. Sicherheitsprüfung über alle Routen

Setzen Sie für jede Route-Datei einen eigenen Subagenten ein.

Jeder Agent sucht nach fehlenden Authentifizierungsprüfungen. Danach folgt eine zusätzliche Verifizierungsrunde, die jeden Fund bestätigt, bevor er in den finalen Bericht aufgenommen wird.

Dadurch entsteht eine Breite, die ein einzelner Kontext niemals gleichzeitig halten könnte.

2. Quellenbasierter Bericht mit /deep-research

Verwenden Sie einen Graphen, der bereits in Claude Code vorhanden ist.

Er zerlegt die ursprüngliche Frage in unterschiedliche Perspektiven, führt die Suchen parallel durch, entfernt doppelte Quellen und überprüft anschließend jede Aussage adversarisch mit Skeptikern und einer Drei-Stimmen-Mehrheit, bevor der Bericht geschrieben wird.

3. Ein Modul Datei für Datei portieren

Teilen Sie die Übersetzung beziehungsweise Portierung über die einzelnen Dateien auf.

Für jede Datei dient die Testsuite als Gate.

Wenn etwas fehlschlägt, wird der Fehler wieder in den Loop zurückgeführt.

Die adversarische Prüfung soll anschließend Fehler entdecken, die bei einem einzigen Durchlauf unbemerkt geblieben wären.

4. Adversarisches Review eines Diffs

Die Größe des Diffs bestimmt den weiteren Weg.

Bei einer kleinen Änderung genügt eine schnelle Prüfung.

Ein größerer Diff löst dagegen ein vollständiges paralleles Audit aus, bei dem verschiedene Prüfer unterschiedliche Perspektiven einnehmen: Korrektheit, Sicherheit und Geschwindigkeit.

Danach führt ein Jury-Panel die Ergebnisse zusammen.

5. Geplanter Scan des Ökosystems

Ein solcher Workflow wird einmal gespeichert und kann anschließend dauerhaft erneut ausgeführt werden.

Viele Quellen werden parallel abgefragt, darunter Releases, Blogs und Foren.

Die Ergebnisse werden an einer Barriere nach ihrer Auswirkung sortiert und anschließend zu einer Zusammenfassung verarbeitet.

Der Workflow wird unter .claude/workflows/ versioniert und kann anschließend über seinen Namen gestartet werden.

6. Entdeckung mit unbekanntem Umfang

Wenn nicht bekannt ist, wie viele Bugs vorhanden sind, werden mehrere Suchagenten parallel eingesetzt.

Jeder neu entdeckte Fund wird gegen alles bisher Gesehene dedupliziert.

Die verbleibenden Ergebnisse werden verifiziert.

Anschließend wird der Loop fortgesetzt, bis zwei aufeinanderfolgende Runden keine neuen Ergebnisse mehr hervorbringen.

Danach wird die Ausführung beendet.

Checkliste vor dem Start des ersten Graphen

• - Habe ich alle Kanten entfernt, über die keine Daten übertragen werden?
• - Ist die Arbeit wirklich aufteilbar oder benötigt jeder Schritt zwingend das Ergebnis des vorherigen?
• - Besitzt jeder Knoten eine klar begrenzte Eingabe, eine strukturierte Ausgabe und genau eine Aufgabe?
• - Verwende ich einen Agenten für eine Tätigkeit, die eigentlich nur ein flatMap erfordern würde?
• - Existieren Barrieren, obwohl die jeweilige Phase nicht die komplette Ergebnismenge benötigt?
• - Kann ein Fund in das finale Ergebnis gelangen, ohne dass ein anderer Agent versucht hat, ihn zu widerlegen?
• - Stellen mehrere Verifizierer dieselbe Frage?
• - Besitzt jeder Loop eine Begrenzung für die Anzahl seiner Runden?
• - Gibt es mehrere Knoten, die gleichzeitig dieselbe Datei schreiben?
• - Werden die repetitiven Aufgaben unnötigerweise mit dem teuersten Modell ausgeführt?

Wenn Sie bei mehr als drei Punkten scheitern, besitzen Sie noch keinen Graphen.

Sie haben lediglich eine Kette mit zusätzlichen Schritten.

Fazit

Wer promptet, stellt eine Frage. Wer Systeme architektonisch denkt, zeichnet einen Graphen.

Der lineare Agent war niemals die eigentliche Obergrenze.

Er war lediglich die erste Form, zu der jeder greift, weil sie unserer gewöhnlichen Art zu schreiben entspricht:

Eine Linie. Ein Kopf. Eine Aufgabe nach der anderen.

Sobald Sie anfangen, in Knoten und Kanten zu denken, hören Sie auf, den Agenten einfach immer mehr Schritte ausführen zu lassen.

Stattdessen lassen Sie den Graphen breiter arbeiten.

Sie fächern die Arbeit dort auf, wo die einzelnen Aufgaben unabhängig voneinander sind.

Sie setzen Kontrollpunkte auf die Kanten, wenn die Zuverlässigkeit der Ergebnisse entscheidend ist.

Und Sie verwenden günstigere Modelle überall dort, wo kein besonderes Urteilsvermögen erforderlich ist.

Die meisten Menschen werden weiterhin ihre Aufgaben Schritt für Schritt hintereinanderreihen.

Diejenigen, die gelernt haben, den Graphen zu entwerfen, werden dagegen eine vollständige Flotte von Agenten bewegen.

Und irgendwann werden sie die niedrige Decke, unter der der Rest feststeckt, überhaupt nicht mehr wahrnehmen.

Zeichnen Sie Ihr derzeitiges System noch heute Abend auf.

Beschränken Sie sich dabei auf die einzelnen Aufgaben und die Pfeile zwischen ihnen.

Identifizieren Sie die Kanten, die eigentlich gar keine echten Abhängigkeiten darstellen, und entfernen Sie sie.

Das ist der erste Schritt dieses Handwerks.

Er kostet nichts und beseitigt normalerweise mehr Wartezeit, als jedes zusätzliche Werkzeug beseitigen könnte.