Dynamische Workflows in Claude Code: Wenn ein Agenten-Schwarm die Arbeit übernimmt
Anthropic hat am 28. Mai 2026 dynamische Workflows in Claude Code veröffentlicht. Die Funktion verteilt komplexe Aufgaben auf einen Schwarm paralleler KI-Agenten, lässt sie ihre Befunde gegenseitig prüfen und läuft im Hintergrund weiter, während die Sitzung bedienbar bleibt. Dieser Artikel erklärt, wie der Schwarm funktioniert, was damit möglich wird und worauf deutsche Unternehmen bei Kosten und Governance achten sollten.
Dynamische Workflows in Claude Code, veröffentlicht am 28. Mai 2026 zusammen mit Claude Opus 4.8, lassen Claude pro Aufgabe ein JavaScript-Orchestrierungs-Skript schreiben, das zehn bis hunderte Subagenten parallel koordiniert. Die Architektur setzt auf adversariale Verifikation: Ein Subagent stellt eine Behauptung auf, ein anderer versucht sie zu widerlegen, und der Lauf iteriert, bis die Ergebnisse konvergieren. Harte Grenzen sind 16 gleichzeitige und maximal 1.000 Agenten pro Lauf. Als Praxisbeleg portierte der Bun-Entwickler die Laufzeit von Zig nach Rust: rund 750.000 Zeilen Rust, 99,8 Prozent der Tests bestanden, 11 Tage bis zum Merge. Der zentrale Vorbehalt ist der Ressourcenverbrauch: Dynamische Workflows verbrauchen deutlich mehr Token als eine normale Sitzung, weshalb die Funktion für Enterprise-Pläne zum Start standardmäßig deaktiviert ist. Für deutsche Unternehmen verschiebt sich der Engpass vom Schreiben des Codes zum Bestätigen, dass er korrekt ist.
Was dynamische Workflows in Claude Code sind
Dynamische Workflows sind eine am 28. Mai 2026 veröffentlichte Funktion, mit der Claude Code komplexe Aufgaben auf zehn bis hunderte parallele Subagenten verteilt und deren Arbeit prüft, bevor ein Ergebnis zurückkommt. Statt einer festen Schrittfolge schreibt Claude pro Aufgabe ein JavaScript-Skript, das die Orchestrierung im Hintergrund steuert, während die Sitzung bedienbar bleibt. Die Funktion erschien zusammen mit Claude Opus 4.8 und befindet sich in einer Research Preview.
Aktiviert wird die Funktion per direkter Aufforderung oder über die Einstellung ultracode, die das Orchestrieren automatisch übernimmt. Für Max- und Team-Pläne ist sie standardmäßig aktiv, für Enterprise zum Start deaktiviert und nur durch Administratoren freischaltbar. Damit ordnet sich der Release in die Entwicklung ein, die innobu im Beitrag zum Agent Control Plane 2026 und dem Wettlauf um den Harness beschrieben hat.
Wie der Agenten-Schwarm funktioniert
Der Kern ist ein selbst geschriebenes Skript, das Arbeit verteilt und Ergebnisse zusammenführt. Claude plant dynamisch anhand der Aufgabe, zerlegt sie in Teilaufgaben, startet Subagenten parallel und lässt andere Subagenten die Befunde widerlegen. Der Lauf wiederholt sich, bis die Antworten stabil bleiben. Drei Prinzipien prägen das Verhalten.
Parallel und Pipeline
Aufgaben laufen gleichzeitig oder als Fliessband, bei dem jedes Element unabhängig durch mehrere Stufen wandert. So bleibt die Gesamtdauer nahe an der langsamsten Einzelkette statt an der Summe aller Schritte.
Adversariale Verifikation
Behauptet ein Agent etwa eine Race Condition, ist es die Aufgabe eines anderen, sie zu widerlegen. Das senkt die Rate plausibler, aber falscher Befunde, weil jede Aussage einen Gegenspieler bekommt.
Konvergenz statt fester Runden
Anzahl der Agenten und Iterationen entscheiden sich zur Laufzeit nach Bedarf der Aufgabe. Der Lauf endet, wenn sich die Antworten nicht mehr ändern, nicht nach einer vorab gesetzten Rundenzahl.
Dazu kommt Robustheit im Betrieb. Fortschritt wird automatisch gesichert, unterbrochene Läufe setzen fort statt neu zu starten, und die Koordination läuft ausserhalb des Gesprächsfensters, damit der Plan auch bei langen Läufen stabil bleibt. Das erklärt das Bild des Entwicklers, der einen Lauf anstösst und sich anderem zuwendet.
Die harten Grenzen sind 16 Agenten gleichzeitig und maximal 1.000 Agenten pro Lauf. Die erste schützt deine lokale Maschine, die zweite ist ein Sicherheitsnetz gegen Endlosschleifen. Beide Zahlen solltest du kennen, bevor du einen großen Lauf startest, denn sie bestimmen Tempo und maximalen Aufwand.
Was damit möglich wird
Dynamische Workflows zielen auf Aufgaben, die für einen einzelnen Agenten zu gross sind: codebasisweite Fehlersuche, große Migrationen, Sicherheitsaudits, Performance-Analysen und Architektur-Reviews über tausende Dateien. Der Reiz liegt darin, dass ein Entwickler einen langen Lauf anstossen und sich anderem zuwenden kann, weil die Verifikation eingebaut ist.
Das prominenteste Beispiel ist die Portierung der Laufzeit Bun von der Sprache Zig nach Rust. Im Lauf kartierte ein Workflow die Rust-Lifetimes, während ein zweiter parallel hunderte Dateien schrieb, mit zwei Prüfern je Datei. Typische Einsätze laut Anthropic sind Framework-Wechsel, API-Deprecations, profilergestützte Optimierung und die Modernisierung großer Bestandssysteme.
Dynamische Workflows füllen die Lücke zwischen dem Start eines einzelnen Subagenten und dem Aufbau eines kompletten Agenten-Teams. Plan und Umsetzung fließen, sodass sich längere Läufe vertrauen lassen.
Ken Takao, Lead Systems Engineer, AnthropicWichtig ist die Einordnung: Das ersetzt nicht jeden Entwickler, sondern verschiebt dessen Rolle. Wer früher selbst Teilaufgaben verteilt und Ergebnisse zusammengeführt hat, definiert jetzt die Aufgabe und prüft das Resultat. Wie sich diese zweite Agenten-Generation in der Praxis verhält, beschreibt der Artikel zur Rebuild-Era der Enterprise-KI-Agenten .
Deutsche und EU-Perspektive
Für deutsche Unternehmen ist die zentrale Frage nicht, ob die Technik beeindruckt, sondern ob sie sich kontrolliert und nachvollziehbar betreiben lässt. Ein Lauf mit hunderten Subagenten erzeugt viele automatisierte Entscheidungen, und der EU AI Act verlangt bei Hochrisiko-Anwendungen Dokumentation, Nachvollziehbarkeit und menschliche Aufsicht. Die eingebaute Verifikation hilft, ersetzt aber keine Governance.
Verifikation wird zur Kernaufgabe: Wenn Code in Minuten entsteht, verschiebt sich der Engpass vom Schreiben zum Bestätigen, dass er korrekt ist. Bei hunderten parallelen Befunden muss die Beweissicherung mit dem Tempo der Erzeugung mithalten, sonst entsteht ein Berg ungeprüfter Ergebnisse.
Hinzu kommt der Datenschutz. Läuft ein Workflow über Amazon Bedrock, Google Vertex AI oder Microsoft Foundry, gelten dieselben Fragen zu Datenstandort und Auftragsverarbeitung wie bei jeder Cloud-KI. EU-regionale oder selbst gehostete Optionen mindern das Risiko. Wer den Einsatz plant, sollte ihn von Beginn an mit den Fristen des EU AI Act für Hochrisiko-Systeme zusammendenken.
Budget bewusst freigeben: Dass die Funktion für Enterprise-Pläne standardmäßig deaktiviert ist, ist kein Mangel, sondern eine Schutzmassnahme. Administratoren können so Budget, Freigabe und Datenfluss steuern, bevor ein Team einen Lauf mit bis zu 1.000 Agenten startet.
Herausforderungen und Risiken
Die Funktion ist eine Research Preview, kein abgeschlossenes Produkt, und bringt reale Risiken mit. Vier Punkte sollten Unternehmen nüchtern bewerten, bevor sie dynamische Workflows in kritischen Pfaden einsetzen.
Token-Eskalation
Dynamische Workflows verbrauchen deutlich mehr Token als eine normale Sitzung, und ein Lauf kann bis zu 1.000 Agenten starten. Agentische Werkzeuge können ein Vielfaches der Token einer einfachen Anfrage verbrauchen. Ohne gesetzte Budgetgrenzen drohen unerwartete Rechnungen, weshalb Anthropic ausdrücklich empfiehlt, mit kleinen, klar umrissenen Aufgaben zu beginnen.
Verifikation bleibt schwer
Adversariale Prüfung senkt die Fehlerrate, garantiert aber keine Korrektheit. Bei hunderten parallelen Befunden braucht es eigene Prüf- und Freigabeprozesse. Die Technik verlagert den schwierigen Teil von der Erzeugung zur Bestätigung, und diese Bestätigung lässt sich nicht vollständig automatisieren.
Zurückhaltung im Enterprise
Berichte über zurückgefahrene KI-Ausgaben, etwa die Kündigung vieler interner Claude-Code-Lizenzen bei Microsoft, zeigen, dass Unternehmen den Nutzen kritisch gegen die Kosten abwägen. Ein Werkzeug, das viel kann, aber auch viel kostet, braucht einen belegbaren Geschäftsnutzen, nicht nur eine beeindruckende Demo.
Reife der Preview
Als Research Preview können sich Verhalten, Preis und Verfügbarkeit ändern. Ein produktiver Einsatz in kritischen Pfaden sollte das einkalkulieren und nicht davon ausgehen, dass die heutigen Bedingungen dauerhaft gelten.
Was Unternehmen jetzt tun sollten
Der sinnvolle Einstieg ist klein und kontrolliert. Wer dynamische Workflows testen will, sollte mit einer abgegrenzten, gut messbaren Aufgabe beginnen, Budgetgrenzen setzen und die Ergebnisse unabhängig prüfen, bevor produktive Pfade angefasst werden. Vier Schritte helfen dabei.
-
Pilot mit klarer Grenze
Wähle eine konkrete, gut messbare Aufgabe, etwa ein Audit eines abgegrenzten Moduls oder eine begrenzte Migration. Definiere den Erfolg vorab, damit du das Ergebnis später eindeutig bewerten kannst.
-
Budget und Freigabe steuern
Schalte die Funktion auf Enterprise-Plänen bewusst frei und lege Token-Limits und Genehmigungen fest. So vermeidest du, dass ein einzelner Lauf mit bis zu 1.000 Agenten unbemerkt das Budget sprengt.
-
Verifikation institutionalisieren
Benenne eine menschliche Prüfinstanz für die Ausgaben und prüfe Befunde stichprobenartig gegen. Die eingebaute adversariale Verifikation ist eine Hilfe, kein Ersatz für fachliche Kontrolle.
-
Governance mitdenken
Klär Risikoklassifizierung nach EU AI Act, Protokollierung der Läufe und Datenstandort von Anfang an. Das ist günstiger, wenn es vor dem ersten produktiven Lauf geschieht, nicht danach.
Wer den Schritt von einzelnen Routinen zu orchestrierten Läufen plant, findet weitere Einordnung in den Artikeln zu Claude Code Routines und Cloud-Automatisierung und zur Preiswende bei KI-Coding-Tools und Token-Abrechnung .
Dynamische Workflows sind kein Selbstläufer, sondern ein Werkzeug mit hohem Hebel und hohen Kosten. Der Wert entsteht durch die richtige Aufgabe, klare Budgetgrenzen und eine menschliche Prüfung. Wer das beachtet, kann große Aufgaben beschleunigen, ohne die Kontrolle abzugeben.
Weiterführende Informationen
Häufig gestellte Fragen
Dynamische Workflows sind eine am 28. Mai 2026 veröffentlichte Funktion von Anthropic, mit der Claude Code komplexe Aufgaben auf zehn bis hunderte parallele Subagenten verteilt und deren Arbeit prüft, bevor ein Ergebnis zurückkommt. Statt einer festen Schrittfolge schreibt Claude pro Aufgabe ein JavaScript-Skript, das die Orchestrierung im Hintergrund steuert, während die Sitzung bedienbar bleibt. Die Funktion erschien zusammen mit Claude Opus 4.8 und befindet sich in einer Research Preview.
Maximal 16 Agenten gleichzeitig und maximal 1.000 Agenten pro Lauf. Die erste Grenze schützt lokale Ressourcen, die zweite verhindert Endlosschleifen. In der Praxis koordiniert ein Workflow zehn bis hunderte Subagenten, deren Anzahl und Iterationen sich zur Laufzeit nach Bedarf der Aufgabe entscheiden. Der Lauf wiederholt sich, bis die Ergebnisse konvergieren.
Als Praxisbeleg nennt Anthropic die Portierung der Laufzeit Bun von der Sprache Zig nach Rust. Das Ergebnis waren rund 750.000 Zeilen Rust, 99,8 Prozent der bestehenden Tests bestanden, und 11 Tage vom ersten Commit bis zum Merge. Im Beispiel lief ein Workflow, der Rust-Lifetimes kartierte, parallel zu einem zweiten, der hunderte Dateien schrieb, mit zwei Prüfern je Datei.
Dynamische Workflows verbrauchen deutlich mehr Token als eine normale Claude-Code-Sitzung, weil ein Lauf bis zu 1.000 Agenten starten kann. Anthropic empfiehlt ausdrücklich, mit kleinen, klar umrissenen Aufgaben zu beginnen. Für Enterprise-Pläne ist die Funktion zum Start standardmäßig deaktiviert, damit Administratoren Budget und Freigabe steuern können. Ohne Budgetgrenzen drohen unerwartete Rechnungen.
Für klar abgegrenzte Aufgaben wie Audits, Migrationen oder Fehlersuche ja, aber kontrolliert. Sinnvoll ist ein kleiner Pilot mit definierten Erfolgskriterien, gesetzten Budgetgrenzen und einer menschlichen Prüfinstanz für die Ergebnisse. Bei Hochrisiko-Anwendungen verlangt der EU AI Act Dokumentation, Nachvollziehbarkeit und menschliche Aufsicht. Die eingebaute Verifikation hilft, ersetzt aber keine Governance.