Die meisten Leute, die versuchen, einen Multi-Step-Agenten zu bauen, landen bei einer geraden Linie. Schritt eins, Schritt zwei, Schritt drei – jeder wartet artig, bis der vorherige fertig ist, bevor er beginnt.
9 von 10 stellen fest, dass die Hälfte dieser Schritte nie hätte warten müssen.
Sie leiten nicht weiter. Sie verzweigen nicht. Sie parallelisieren nicht. Sie reihen sich nur ein – ein Kopf, ein Kontext, eine Sache nach der anderen, bis das Fenster voll ist und der Agent vergisst, was er gerade tat.
Folge meinem Substack, um frische KI-Alpha-Informationen zu erhalten:
Dies ist die 14-Schritte-Roadmap, die diese einzelne Warteschlange in einen Graphen verwandelt: einen, der sich über eine Flotte ausbreitet, seine eigenen Ergebnisse verifiziert und zu einem Ergebnis zusammenführt, das ein einzelner Agent niemals halten könnte.
Hier ist die Verschiebung, die niemand klar ausspricht. Ein Prompt ist ein Satz. Eine Schleife ist ein Zyklus. Ein Geschirr ist der Boden, auf dem der Agent steht.
Aber die Form der Arbeit selbst – was läuft vor was, was kann gleichzeitig laufen, was muss auf alles andere warten – diese Form ist ein Graph. Knotenpunkte leisten die Denkarbeit. Kanten transportieren die Ergebnisse.
Claude Code hat die Werkzeuge geliefert, um diese Graphen direkt zu bauen: dynamische Workflows.
Claude schreibt ein einfaches JavaScript-Orchestrierungsskript, erzeugt dann eine koordinierte Flotte von Unteragenten, um es auszuführen – und die Koordination selbst kostet null Modell-Token, weil sie Code ist, kein Gespräch.
01. Knoten sind Jobs. Kanten sind das, was fließt.
Ein Graph hat genau zwei Dinge, und wenn man diese klar hat, löst sich der Großteil der Verwirrung. Ein Knoten ist eine Arbeitseinheit – ein Agent, ein abgegrenzter Job, eine Eingabe rein und eine Ausgabe raus.
Eine Kante ist eine Abhängigkeit: Sie besagt, dass die Ausgabe dieses Knotens die Eingabe jenes Knotens speist. Nichts weiter.
Der Fehler ist, "und dann" als eine Kante zu behandeln. "Fasse die Datei zusammen und dann sag mir das Wetter" hat keine Kante zwischen den beiden – das Wetter verbraucht die Zusammenfassung nicht.
Das sind zwei nicht verbundene Knoten, die ein lineares Skript unnötig aneinanderkettet. Die Kante existiert nur, wenn Daten tatsächlich darüber fließen.
Lerne, bei jedem "und dann" in deinem Agenten zu fragen: Liest der nächste Schritt die Ausgabe des letzten Schrittes? Wenn nicht, gibt es keine Kante, und das Warten ist verschwendet.
1Zeichne es als Kästen und Pfeile. Ein Kasten ist ein agent()-Aufruf.2Ein Pfeil ist eine Variable, die vom Rückgabewert eines Aufrufs in den3Prompt eines anderen übergeben wird. Wenn du den Pfeil nicht zeichnen4kannst – wenn keine Variable die Grenze überschreitet – sind die beiden5Kästen unabhängig, und Unabhängigkeit ist das, was du für den Rest6dieses Kurses ausnutzen wirst.
02. Dein lineares Skript ist ein degenerierter Graph
Wenn du einen Agenten schreibst als "mach A, dann B, dann C, dann D", hast du einen Graphen gezeichnet – eine einzige, unverzweigte Kette. Jeder Knoten hat genau eine Kante rein und eine Kante raus.
Es läuft korrekt. Aber es läuft auch langsam und anfällig, weil eine Kette keine Redundanz hat: Wenn C stockt, passiert D nie, und die Arbeit von A ist stromaufwärts gefangen, ohne wohin zu können.
Die erste wirkliche Fähigkeit des Graphen-Engineerings ist das Neuzeichnen der Kette. Nimm deinen linearen Agenten und frage für jeden Pfeil die Frage aus Schritt 1.
Die meisten Ketten haben zwei oder drei Pfeile, die keine Daten transportieren – sie sind nur die Reihenfolge, in der du zufällig die Dinge eingetippt hast.
Schneide diese Pfeile ab, und die Kette kollabiert zu etwas Breiterem: ein paar unabhängige Knoten, die alle gleichzeitig laufen könnten und einen einzelnen Knoten speisen, der sie alle braucht.
03. Gib jedem Knoten einen Vertrag
Ein Knoten, über den du keine Aussagen treffen kannst, ist ein Knoten, den du nicht parallelisieren kannst. Die Lösung ist ein Vertrag: begrenzte Eingabe, begrenzte Ausgabe, genau ein Job.
Die Eingabe ist das, was der Knoten liest – explizit übergeben, niemals aus einem gemeinsamen Fenster angenommen. Die Ausgabe ist eine definierte Form, idealerweise validiert, sodass der nächste Knoten sie verbrauchen kann, ohne raten zu müssen.
In einem Workflow wird dieser Vertrag mit einem Schema durchgesetzt. Wenn du Claude einen agent()-Aufruf mit einem JSON-Schema übergibst, wird der erzeugte Unteragent Claude gezwungen, validierte strukturierte Daten zurückzugeben – die Validierung erfolgt auf der Ebene des Tool-Aufrufs, sodass Claude bei Nichtübereinstimmung wiederholt, anstatt dir Freitext zu geben, den du parsen und beten musst.
Das ist der Unterschied zwischen einem Knoten, den Claude in einen Graphen einbinden kann, und einem Knoten, der nur funktioniert, wenn ein Mensch seine Ausgabe liest.
1// Ein Knoten mit einem echten Vertrag: begrenzt rein, validiert raus, ein Job.2const ITEM = {3 type: 'object', additionalProperties: false,4 properties: {5 title: { type: 'string' },6 url: { type: 'string' },7 impact: { type: 'string', enum: ['high', 'medium', 'low'] },8 },9 required: ['title', 'url', 'impact'],10};1112const result = await agent(source.prompt, {13 label: `research:${source.key}`,14 schema: ITEM, // erzwingt validierte strukturierte Ausgabe15 agentType: 'general-purpose',16});17// result ist jetzt eine Form, der der nächste Knoten vertrauen kann – kein Freitext.
04. Behandle die Kante als einen Datenvertrag
Eine Kante ist nicht nur "B kommt nach A." Es ist ein Versprechen darüber, was die Grenze überschreitet: A produziert diese Form, und B ist gebaut, um diese Form zu verbrauchen. Wenn du die Kante nach ihren Daten benennst – nicht nach ihrer Reihenfolge – werden zwei Dinge einfacher.
Du kannst sofort sehen, ob die Kante echt ist (bewegen sich Daten tatsächlich?), und du kannst den Knoten an jedem Ende austauschen, ohne den Graphen zu brechen, solange die Form erhalten bleibt.
In der Praxis lebt die Kante in einfachem JavaScript. Der Reduce-Schritt zwischen Fan-Out und Synthese – glätten, deduplizieren, filtern – ist nur Code, der auf den Formen operiert, die deine Knoten zurückgegeben haben.
Kein Agent nötig. Einer der stillen Siege des Graphen-Denkens: Eine riesige Menge dessen, wofür Leute Modell-Token verbrennen, ist in Wirklichkeit eine Kante, und Kanten sind kostenlos.
1Die Versuchung ist, einen Agenten zu beauftragen, "die Ergebnisse zu2kombinieren." Widerstehe ihr. Wenn Kombinieren Glätten-und-Deduplizieren3bedeutet, sind das results.flatMap(...) und ein Set – deterministisch,4sofort, null Token. Spare Agenten für Beurteilungen auf, nicht für5Rohrleitungen. Ein Graph, in dem jede Kante ein Agent ist, ist ein6Graph, der Miete für seine eigene Verkabelung zahlt.
05. Verteile dich mit parallel()
Das ist der Zug, der alles bezahlt macht. Wenn du N unabhängige Knoten hast – N Quellen, die du überprüfen musst, N Dateien, die du prüfen musst, N Routen, die du prüfen musst – dann kettest du sie nicht aneinander.
Du sagst Claude, er soll sie verteilen und alle auf einmal laufen lassen. In einem Workflow ist das parallel(): Claude nimmt ein Array von Thunks und erzeugt einen Unteragenten pro Thunk, die alle gleichzeitig ausgeführt werden, und gibt dir dann das Array der Ergebnisse zurück.
Zwei Details machen es robust. Erstens ist parallel() eine Barriere – es wartet auf jeden Thunk, bevor es zurückkehrt, sodass die nächste Stufe den vollständigen Satz sieht. Zweitens löst ein Thunk, der einen Fehler wirft, sich zu null auf, anstatt die gesamte Charge abzulehnen, sodass ein einzelner unzuverlässiger Agent den Lauf nicht versenken kann.
Filtere die Ergebnisse immer mit .filter(Boolean). Die Parallelität ist um deine Kernanzahl begrenzt, und der Überschuss wird in die Warteschlange gestellt, sodass du hundert Thunks übergeben kannst und sie alle fertig werden – nur ein paar auf einmal.
1phase('Research');23// Neun Quellen, neun Agenten, alle gleichzeitig.4const raw = await parallel(5 SOURCES.map((s) => () =>6 agent(s.prompt, {7 label: `research:${s.key}`,8 phase: 'Research',9 schema: ITEM_SCHEMA, // jeder Knoten gibt validiertes JSON zurück10 agentType: 'general-purpose',11 }),12 ),13);1415const collected = raw.filter(Boolean); // Null-Werte von fehlgeschlagenen Agenten verwerfen
Die Verteilung lebt in Code, den Claude geschrieben hat, nicht in einer Modell-Konversation. Clau-de eigener Kontext enthält nie neun Quellen gleichzeitig – jeder Unteragent trägt seine eigene, und nur die endgültige Antwort kommt zurück.
Das ist es, was Claude erlaubt, einen Workflow auf Dutzende oder Hunderte von Unteragenten zu skalieren, ohne die Sitzung zu ertränken. Die Orchestrierungsschicht kostet null Token, weil sie keine weitere Runde von Claudes Denken ist.
06. Führe an einer Barriere zusammen
Eine Verteilung ist nur nützlich, wenn etwas sie einsammelt. Die Zusammenführung ist der Knoten, an dem Kanten zusammenlaufen – wo ein Agent (oder ein Stück Code) alle Ergebnisse der vorherigen Stufe auf einmal sieht und etwas tut, das den gesamten Satz erfordert: Quellenübergreifendes Deduplizieren, nach Auswirkung ordnen, vorzeitiger Abbruch, wenn die Gesamtmenge leer zurückkam. Dies ist der eine Ort, an dem eine Barriere ihre Wanduhrzeit wert ist.
Die Regel, die Graphen schnell hält: Verwende eine Barriere nur, wenn eine Stufe wirklich alle vorherigen Ergebnisse zusammen braucht. Deduplizieren über alle Quellen hinweg? Barriere – korrekt.
1// Die Kante: reines JS, kein Agent, null Token.2const flat = collected.flatMap((c) => c.items);3log(`Sammelte ${flat.length} Elemente`);45phase('Curate');6// Der Barriere-Knoten: braucht den GESAMTEN Satz zum Deduplizieren + Ordnen.7const curated = await agent(8 `Dedupliziere und ordne diese nach Auswirkung:\n${JSON.stringify(flat)}`,9 { phase: 'Curate', schema: CURATED_SCHEMA },10);
Nur eine Liste glätten? Das ist eine Kante, mach es inline. Der Geruchstest ist brutal und einfach: Wenn du parallel → transform → parallel geschrieben hast und diese mittlere Transformation keine querelementbezogene Abhängigkeit hat, hättest du eine Pipeline verwenden und die Barriere ganz überspringen sollen.
07. Der Diamant: aufteilen → arbeiten → zusammenführen
Setze Fan-Out und Fan-In zusammen, und du erhältst die Arbeitstier-Topologie jedes ernsthaften Agentengraphen: den Diamanten.
Ein Knoten teilt den Job, viele Knoten erledigen die Arbeit parallel, ein Knoten führt zusammen. Es ist die Form hinter einem Markt-Scan, einer Abhängigkeitsprüfung, einer Code-Review, einem Forschungsbericht – tausche die Quellen und Prompts aus, und dasselbe Grundgerüst passt sich an.
Die kanonische Form hat einen Namen, den es sich zu merken lohnt: ausbreiten → reduzieren → synthetisieren. Ausbreiten, um Breite zu sammeln, mit einfachem Code reduzieren, um es zu komprimieren, mit einem letzten Agenten synthetisieren, um die Antwort zu schreiben.
Sobald du den Diamanten siehst, hörst du auf zu fragen "Wie bringe ich meinen Agenten dazu, mehr Schritte zu machen?" und beginnst zu fragen "Wo ist die Aufteilung, wo ist die Zusammenführung?" – das ist die Frage, die tatsächlich skaliert.
08. Leite die Kante zur Laufzeit mit einer Bedingung um
Nicht jeder Graph ist festgelegt. Manchmal hängt die zu nehmende Kante davon ab, was ein Knoten gefunden hat. Ein Router-Knoten inspiziert ein Ergebnis und entscheidet, welcher nachgelagerte Pfad ausgelöst wird – klassifiziere das Ticket, verzweige dann zum richtigen Bearbeiter; überprüfe die Diff-Größe, führe dann entweder eine schnelle Überprüfung durch oder starte eine vollständige Prüfung.
In einem Workflow ist das einfach ein JavaScript if oder switch auf der validierten Ausgabe eines Knotens, weil der Kontrollfluss in Code lebt.
Hier wird Determinismus zu einem Feature, nicht zu einer Einschränkung. Die Entscheidung des Routers kann von Claude gesteuert werden (ein Unteragent klassifiziert), aber das Routing ist Code, den Claude geschrieben hat – also läuft es für dieselbe Klassifikation jedes Mal gleich ab.
Du bekommst Claudes Urteilsvermögen am Knoten und die Zuverlässigkeit des Skripts an der Kante. Keine auftauchenden Überraschungen wie "Claude hat beschlossen, die Prüfung zu überspringen" – denn das Überspringen müsste in den Graphen geschrieben worden sein, und das ist es nicht.
1// Router-Knoten: Ein Agent klassifiziert, Code wählt die Kante.2const { severity } = await agent(3 `Klassifiziere das Risiko dieses Diffs:\n${diff}`,4 { schema: { type: 'object',5 properties: { severity: { enum: ['low', 'high'] } },6 required: ['severity'] } },7);89let review;10if (severity === 'high') {11 // schwerer Pfad: vollständige parallele Prüfung12 review = await parallel(FILES.map((f) => () => agent(`Prüfe ${f}`)));13} else {14 // leichter Pfad: ein schneller Durchlauf15 review = await agent(`Schnelle Überprüfung von ${diff}`);16}
09. Setze einen Verifizierer auf die Kante
Der wahre Hebel eines Graphen sind nicht mehr Agenten – es ist die Struktur, die du um sie herum legen kannst, um Vertrauen zu erzeugen.
Ein Verifizierer-Knoten sitzt auf der Kante, bevor ein Ergebnis flussabwärts weitergegeben werden darf, und seine einzige Aufgabe ist es, zu versuchen, den Befund zu widerlegen. Wenn er überlebt, passiert er. Wenn nicht, erreicht er nie die Antwort.
Drei Muster sind es wert, sie parat zu haben.
- Adversarial verifizieren: Erzeuge für jeden Befund N unabhängige Skeptiker, die darauf trainiert sind, ihn zu widerlegen; behalte ihn nur, wenn eine Mehrheit überlebt.
- Perspektivenvielfalt verifizieren: Gib jedem Verifizierer eine andere Linse – Korrektheit, Sicherheit, lässt es sich reproduzieren – weil Vielfalt Fehlermodi erwischt, die N identische Prüfungen niemals finden werden.
- Richtergremium: Erzeuge N Versuche aus verschiedenen Blickwinkeln, bewerte sie mit parallelen Richtern, synthetisiere aus dem Gewinner, während du die besten der Zweitplatzierten einpfropfst.
Dies ist genau das Muster, das einem echten Team erlaubte, die Bun-Laufzeit mit adversarialer Code-Review, die in die Schleife eingebaut war, zu portieren.
10. Isoliere Knoten, sodass ein Fehler den Graphen nicht vergiften kann
In einer Kette kaskadiert ein Fehler – C stirbt, D läuft nie, das Ganze stoppt. In einem Graphen sollte ein Fehler auf seinen Knoten beschränkt sein.
Das ist bereits teilweise wahr: Ein Thunk, der einen Fehler innerhalb von parallel() wirft, löst sich zu null auf, sodass acht gute Agenten immer noch zurückkehren, während ein schlechter ausfällt. Dein .filter(Boolean) ist die Eindämmung.
Entwirf jede Zusammenführung so, dass sie fehlende Eingaben toleriert, anstatt einen vollständigen Satz vorauszusetzen.
Der subtilere Fehler sind Knoten, die sich gegenseitig ins Gehege kommen. Wenn Agenten parallel Dateien schreiben, können sie kollidieren.
Die Lösung ist Isolation: "Worktree" – jeder Agent läuft in seinem eigenen git Worktree, erledigt seine Arbeit in einer Sandbox und führt sauber zusammen.
Greife nur dann danach, wenn Knoten tatsächlich parallel schreiben. Es ist der Sicherheitsgurt für die eine Topologie, die ihn braucht, keine Standardsteuer für jeden Lauf.
11. Füge einen Zyklus hinzu – aber lass ihn konvergieren
Manchmal weißt du nicht, wie groß der Job ist, bis du mittendrin bist: Erkundung unbekannter Größe, eine Fehlersuche, bei der das Finden eines Fehlers drei weitere enthüllt. Das braucht einen Zyklus – eine kontrollierte Kante zurück zu einem früheren Knoten.
Die Gefahr ist offensichtlich: Ein Zyklus, der nicht konvergiert, ist eine Endlosschleife, die Agenten erzeugt, bis dein Budget aufgebraucht ist.
Das Muster, das konvergiert, ist Schleife-bis-trocken: Erzeuge weiterhin Findungsagenten, bis K aufeinanderfolgende Runden nichts Neues an die Oberfläche bringen, dann stoppe. Das eine Detail, das es ausmacht oder zerstört – und der Fehler, den fast jeder beim ersten Mal macht – ist, wogegen du deduplizierst.
Dedupliziere gegen alles Gesehene, nicht nur gegen bestätigte Ergebnisse. Sonst tauchen abgelehnte Befunde in jeder Runde wieder auf, die Schleife läuft nie trocken, und du hast eine Maschine gebaut, die dafür bezahlt, dieselben Sackgassen für immer wiederzuentdecken.
1const seen = new Set(); const confirmed = []; let dry = 0;23while (dry < 2) { // stoppe nach 2 leeren Runden4 const found = (await parallel(5 FINDERS.map((f) => () => agent(f.prompt, { schema: BUGS }))6 )).filter(Boolean).flatMap((r) => r.bugs);78 const fresh = found.filter((b) => !seen.has(key(b)));9 if (!fresh.length) { dry++; continue; } // nichts Neues → in Richtung trocken10 dry = 0;11 fresh.forEach((b) => seen.add(key(b))); // dedupliziere gegen GESEHEN, nicht bestätigt1213 // Überprüfe jeden neuen Befund mit verschiedenen Linsen, bevor er zählt14 const judged = await parallel(fresh.map((b) => () =>15 parallel(['correctness', 'security', 'repro'].map((lens) => () =>16 agent(`Beurteile "${b.desc}" via ${lens} — echt?`, { schema: VERDICT })))17 .then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))));1819 confirmed.push(...judged.filter((v) => v.real).map((v) => v.b));20}
12. Abstufung der Modelle über die Knoten hinweg
Nicht jeder Knoten braucht dein bestes Modell. Ein Graph macht dies auf eine Weise offensichtlich, die ein einzelner Agent nie tut: Einige Knoten sind begrenzt und repetitiv (extrahiere dieses Feld, klassifiziere dieses Ticket), und einige tragen das eigentliche Urteilsvermögen (synthetisiere den Bericht, entscheide den Befund).
Lass die langweiligen Knoten auf einem günstigeren Modell laufen und gib deine teuren Token dort aus, wo das Urteilsvermögen tatsächlich lebt.
In einem Workflow erbt jeder Unteragent, den Claude erzeugt, dein Sitzungsmodell, es sei denn, das Skript überschreibt es – standardmäßig wird ein großer Lauf also vollständig zu deiner Sitzungsstufe abgerechnet. Die model-Option bei einem einzelnen agent()-Aufruf sagt Claude, dass er nur diesen Knoten woanders hinleiten soll.
Überprüfe /model vor einem großen Lauf, lass Claude dann die repetitiven Knoten des Fan-Outs auf ein günstigeres Modell herunterstufen und den Merge-Knoten oben behalten. Das ist der Hebel, der einen tokenhungrigen Graphen von teuer zu wirtschaftlich macht, ohne seine Form zu berühren.
13. Topologie ist deine Kosten und Latenz
Die Form des Graphen ist nicht kosmetisch – sie ist der mit Abstand größte Hebel für die Wanduhrzeit. Die Entscheidung, die alle stolpern lässt: parallel() versus pipeline(). Eine parallel()-Barriere lässt alles auf den langsamsten Knoten warten, bevor die nächste Stufe beginnt.
Eine pipeline() leitet jedes Element unabhängig durch alle Stufen, ohne Barriere – Element A kann in Stufe 3 sein, während Element B noch in Stufe 1 ist. Schnelle Elemente werden früh fertig, anstatt hinter langsamen herumzustehen.
Standardmäßig pipeline(). Greife nur dann zu einer Barriere, wenn eine Stufe wirklich alle vorherigen Ergebnisse auf einmal braucht – eine quellenübergreifende Deduplizierung, ein vorzeitiger Abbruch basierend auf der Gesamtmenge, ein Prompt, der gegen "die anderen Befunde" vergleicht. "Es ist sauberer Code" und "die Stufen fühlen sich getrennt an" sind keine Gründe; Barriere-Latenz ist echte, messbare, verschwendete Zeit. Getrennt ist nicht dasselbe wie synchronisiert.
14. Lass Claude den Graphen zeichnen – selbst-lenkend
Der letzte Schritt ist, aufzuhören, den Graphen von Hand für Jobs zu zeichnen, die du nicht im Voraus planen kannst.
Mit dynamischen Workflows beschreibst du das Ziel, und Claude schreibt das Orchestrierungsskript selbst – zerlegt die Aufgabe, wählt das Fan-Out, erzeugt eine koordinierte Flotte von Unteragenten und synthetisiert das Ergebnis. Du bekommst einen Graphen, der auf diesen Lauf zugeschnitten ist, anstatt einen festen, von dem du gehofft hast, dass er passt.
Es gibt drei Wege hinein. Sage das Wort "Workflow" in deinem Prompt, und Claude schreibt einen für die Aufgabe. Führe einen gespeicherten oder gebündelten aus – /deep-research ist ein echter Graph, der in Produktion läuft: Umfang → parallele Suche → Abrufen → adversarial verifizieren → synthetisieren, exakt das Grundgerüst aus diesem Kurs.
Oder schalte Ultracode ein, und Claude plant einen Workflow für jede substanzielle Aufgabe in der Sitzung. Wenn ein Lauf gut ist, drücke s, um sein Skript in .claude/workflows/ zu speichern – versionsverwaltet, nach Namen erneut ausführbar, ein Graph, den jeder, der das Repo klont, starten kann.
1› Führe einen Workflow aus, um jede Route unter src/routes/ auf fehlende2Authentifizierung zu prüfen. Erzeuge einen Agenten pro Routendatei, überprüfe dann jeden Befund,3bevor du berichtest. ● Claude hat ein Orchestrierungsskript geschrieben · starte im4Hintergrund… /workflows — auth-audit · läuft ✓ Umfang 1/1 2,1k Token ·54s ✓ Verteilen 18/18 ein Agent pro Routendatei ◯ Verifizieren 11/18 3-Stimmen-Skeptiker pro Befund… ○ Synthetisieren 0/1 warte auf Verifizierung Sitzung bleibt reaktionsfähig — arbeite weiter, während die Flotte läuft
Sechs Graphen zum Bauen mit Claude diese Woche
- Sicherheitsscan über jede Route. Claude erzeugt einen Unteragenten pro Routendatei, jeder jagt nach fehlenden Authentifizierungsprüfungen, dann stellt ein Verifizierer-Durchlauf sicher, dass jeder Befund den Bericht erreicht. Breite, die kein einzelner Kontext halten könnte.
- Zitierter Bericht mit /deep-research. Ein Graph, der bereits in Claude Code ausgeliefert wird. Claude zerlegt deine Frage in verschiedene Blickwinkel, führt parallele Suchen durch, dedupliziert Quellen, dann überprüft er jede Behauptung adversarially mit Drei-Stimmen-Skeptikern, bevor er schreibt.
- Portiere ein Modul, Datei für Datei. Die Bun-Obergrenze, skaliert auf dein Repo. Claude verteilt die Übersetzung über Dateien, führt die Testsuite als Tor für jede durch und schleust die Fehlschläge zurück – adversarial Review, die abfängt, was ein einzelner Durchlauf als defekt ausliefern würde.
- Adversarial Review eines Diffs. Claude leitet basierend auf der Diff-Größe: eine kleine Änderung bekommt einen schnellen Durchlauf, eine große löst eine vollständige parallele Prüfung mit Prüfern auf verschiedenen Linsen aus – Korrektheit, Sicherheit, Leistung – dann synthetisiert ein Richtergremium.
- Ökosystem-Scan nach Zeitplan. Einmal speichern, für immer erneut ausführen. Claude überprüft viele Quellen parallel – Releases, Blogs, Diskussionen – ordnet nach Auswirkung an einer Barriere und schreibt die Zusammenfassung. Versionsverwaltet in .claude/workflows/, nach Namen startbar.
- Erkundung unbekannter Größe. Du weißt nicht, wie viele Fehler es gibt. Claude lässt Findungsagenten parallel laufen, dedupliziert jeden neuen Fund gegen alles Gesehene, überprüft Überlebende und schleift weiter, bis zwei Runden nichts Neues ergeben – dann stoppt er.
Fazit:
Ein Prompt-Autor stellt eine Frage. Ein Architekt zeichnet einen Graphen.
Der lineare Agent war nie die Obergrenze – er war nur die erste Form, die, nach der jeder greift, weil sie zu unserem Tippen passt. Eine Linie, ein Kopf, eine Sache nach der anderen.
Sobald du die Knoten und Kanten sehen kannst, hörst du auf, den Agenten zu bitten, mehr zu tun, und fängst an, den Graphen zu bitten, es breiter zu machen: verteile dich, wo die Arbeit unabhängig ist, schotte die Kanten ab, wo Vertrauen wichtig ist, stufe die Modelle ab, wo Urteilsvermögen nicht gefragt ist.
Die meisten Leute werden weiterhin Schritte in einer Reihe anordnen. Diejenigen, die lernen, den Graphen zu zeichnen, werden eine Flotte betreiben – und nie die Obergrenze bemerken, unter der der Rest festsitzt.
