Claude Code Dynamic Workflows: Agenten-Orchestrierung

Am 28. Mai 2026 veröffentlichte Anthropic Claude Code 2.1.154 mit einer Funktion, die verändert, wie sich agentisches Coding skalieren lässt: Dynamic Workflows. Statt eine schwierige Aufgabe Schritt für Schritt abzuarbeiten, schreibt Claude jetzt sein eigenes Orchestrierungsskript und verteilt die Arbeit auf zehn bis hunderte Hintergrund-Subagenten in einer einzigen Session.

Dynamic Workflows in Claude Code sind JavaScript-Orchestrierungsskripte, die Claude für eine von dir beschriebene Aufgabe schreibt. Eine Hintergrund-Runtime führt das Skript aus, koordiniert viele Subagenten parallel, hält Zwischenzustände in Skriptvariablen und verifiziert Ergebnisse, bevor sie bei dir ankommen.

Das klingt nach einem kleinen CLI-Update. Ist es nicht. Es verlagert die Orchestrierung aus dem Chat-Turn heraus in Code — und für Teams, die agentisches Coding im Produktivmaßstab betreiben, ändert das die Kapazitäts- und Kostenrechnung. Hier ist, was tatsächlich ausgeliefert wurde, was es architektonisch bedeutet und wie ein Dev-Studio über die Einführung nachdenken sollte.

Was Dynamic Workflows wirklich sind

Ein Dynamic Workflow ist ein JavaScript-Skript, das Subagenten im großen Stil orchestriert; Claude schreibt das Skript für die von dir beschriebene Aufgabe, und eine Runtime führt es im Hintergrund aus, während deine Session reaktionsfähig bleibt (Claude Code Docs).

Die Mechanik ist entscheidend. Im alten Modell koordinierte eine einzige Konversation alles: Jedes Subagenten-Ergebnis floss zurück in ein Kontextfenster, und das Fenster füllte sich schnell. Dynamic Workflows drehen das um. Die Orchestrierungslogik — Schleifen, Verzweigungen, Entscheidungen über die Agentenanzahl, Verifikationsdurchläufe — lebt in Skriptvariablen, und das Kontextfenster des Modells erhält nur die verdichteten Ergebnisse (TechTimes). Das Skript hält den Zustand; das Modell hält das Urteil.

Laut Anthropic schreibt Claude "seine eigenen Orchestrierungsskripte, verteilt die Arbeit auf zehn bis hunderte parallele Subagenten in einer einzigen Session und verifiziert seine eigenen Ergebnisse, bevor irgendetwas bei dir ankommt" (Anthropic). Die Research Preview unterstützt Berichten zufolge bis zu 1.000 Subagenten pro Workflow (Pasquale Pillitteri). Du löst sie aus und inspizierst sie mit dem neuen Befehl /workflows (Claude Code Changelog).

Das ist dieselbe Verschiebung, die wir markierten, als das Multi-Agenten-Cockpit in der Claude Code Agent View ankam: Die Arbeitseinheit ist nicht mehr ein Prompt, sondern eine koordinierte Flotte.

Warum das ein Paradigmensprung ist, kein Patch

Die Schranke, die Dynamic Workflows aufbrechen, ist der Single-Context-Window-Flaschenhals — die harte Obergrenze dafür, wie viel parallele Arbeit eine einzelne Konversation je koordinieren konnte.

Vor Dynamic Workflows war die Zahl der Subagenten, die eine Aufgabe nutzen konnte, durch das begrenzt, was eine einzelne Konversation verfolgen konnte. Indem die Koordination in ein Skript verlagert wird, hebt Claude Code diese Grenze auf und lässt eine Session hunderte Agenten gleichzeitig orchestrieren.

Claude Code bietet jetzt drei eigenständige Kollaborations-Primitive — Dynamic Workflows, Subagents und Agent Teams — und das richtige für die Struktur deines Problems zu wählen, ist kein Nice-to-have mehr (Ken Huang). Subagents übernehmen begrenzte Delegation. Agent Teams übernehmen persistente, rollenbasierte Zusammenarbeit. Dynamic Workflows übernehmen den Fall, in dem eine Aufgabe schlicht mehr Agenten braucht, als eine Konversation koordinieren kann.

Die Skalierungsbehauptungen sind real, am oberen Ende extrem. Ein berichteter Fall hatte einen Workflow, der 750.000 Zeilen Rust in 11 Tagen generierte — nicht auf jedem Projekt reproduzierbar, aber ein klares Signal, wo die Obergrenze jetzt liegt (Pasquale Pillitteri). Die Formulierung von Anthropic ist unverblümt: Arbeit, die du normalerweise in Quartalen planen würdest, kann in Tagen fertig sein (r/ClaudeAI).

Das trifft direkt die These, die wir in Anthropics 2026 Agentic-Coding-Report: Orchestrierungs-Ära vertreten haben: Der Differenzierungsfaktor ist nicht mehr die reine Modellqualität, sondern die Orchestrierung.

Dynamic Workflows kamen mit Opus 4.8

Claude Code 2.1.154 lieferte Dynamic Workflows nicht allein aus — es landete zusammen mit Claude Opus 4.8, das jetzt standardmäßig auf High Effort läuft, mit /effort xhigh für die schwierigsten Aufgaben (Classmethod).

Die Kopplung ist beabsichtigt. Ein stärkeres Orchestrierungsmodell, das die Skripte schreibt, bedeutet bessere Entscheidungen über die Agentenanzahl und straffere Verifikationsdurchläufe. Das Modell selbst haben wir in Anthropics Next Wave: Opus 4.8, Sonnet 4.8, Mythos behandelt; die Neuigkeit hier ist, was dieses Modell jetzt im Hintergrund für dich tut.

Zwei operative Hinweise. Erstens: High Effort als Standard verändert den Token-Verbrauch — plane es ein. Zweitens: Nach 2.1.154 folgten schnell Point Releases, darunter Korrekturen am Verhalten von Opus 4.8, also nutze das neueste Claude Code, statt dich auf den ersten Drop festzunageln (Claude Code Changelog).

Die Kapazitäts- und Kostenrechnung ändert sich

Dynamic Workflows verändern die Kostengleichung genauso stark wie die Kapazitätsgleichung: Hunderte parallele Agenten bedeuten mehr Durchsatz, aber auch eine höhere Rechnung, wenn du die Agentenzahl nicht steuerst.

Parallele Subagenten erhöhen sowohl Geschwindigkeit als auch Kosten. Dynamic Workflows bleiben wirtschaftlich, wenn man steuert, wie viele Agenten eine Aufgabe startet, und Ergebnisse günstig verifiziert, statt jede Aufgabe bis zur maximalen Agentenzahl auffächern zu lassen.

Die Kostenanalyse von Claude Code-Agenten zeigt: Die eigentliche Frage ist nicht mehr der Preis einer einzelnen Completion, sondern was parallele Sessions tatsächlich kosten — und dass die größten Einsparungen daraus kommen, die Agentenzahl an die Aufgabenstruktur anzupassen, nicht daraus, Fähigkeiten zu beschneiden (CloudZero). Das ist dieselbe Brille "Kosten pro akzeptiertem Ergebnis", die wir in Anthropic Token-Ökonomie angelegt haben.

Für eine Agentur ist die Verschiebung strukturell. Eine Abrechnung rund um Entwicklerstunden passt schlecht zu einem Werkzeug, das ein Quartal Arbeit in Tage komprimiert. Die verteidigbare Position ist, Orchestrierungseffizienz und verifizierte Ergebnisse zu bepreisen — was nur funktioniert, wenn du beweisen kannst, dass das Ergebnis korrekt ist.

Wie ein Dev-Studio das einführen sollte

Führe Dynamic Workflows dort ein, wo die Arbeit wirklich parallel und verifizierbar ist — große Refactorings, breite Testgenerierung, Multi-File-Migrationen — und behalte ein menschliches Freigabe-Gate für alles, was die Kern-Geschäftslogik berührt.

Der Verifikationsschritt ist das ganze Spiel. Anthropic hat Selbstverifikation in die Workflow-Runtime eingebaut, aber Selbstverifikation ist nicht dasselbe wie deine Verifikation. Die Disziplin, für die wir in Tokenmaxxing braucht Reviewmaxxing argumentiert haben, gilt jetzt umso härter: Mehr Agenten, die mehr Code produzieren, bedeuten, dass der Review-Durchsatz zum Flaschenhals wird, nicht der Generierungs-Durchsatz.

Praktische Sequenz für Teams:

Beginne mit begrenzten, parallelen Aufgaben. Testgenerierung über ein Modul, ein Dependency-Bump über viele Dateien, ein Dokumentationsdurchlauf. Leicht zu verifizieren, geringer Wirkungsradius.
Nutze Hintergrund-Sessions, um Menschen nicht zu blockieren. Laufende Agenten listest du mit /sessions, eine setzt du mit /switch <session-id> fort (MindStudio).
Behandle langlaufende Agenten wie langlaufende Prozesse. Die Muster für Hintergrund-Agenten in Claude Code 2.1 ähneln eher Service-Betrieb als Chat-Turns — Observability und sauberes Herunterfahren zählen (CallSphere).
Steuere die Agentenzahl. Standard ist die kleinste Flotte, die die Aufgabe löst; reserviere Läufe mit hunderten Agenten für nachweislich parallele Arbeit.

Nichts davon ist Vibe Coding. Es ist die Engineering-Disziplin, die wir in Agentic Engineering ist kein Vibe Coding beschrieben haben, jetzt mit weit größerem Wirkungsradius.

Wo Dynamic Workflows schiefgehen können

Der Fehlermodus ist nicht schlechter Code — es ist nicht überprüfbarer Code in einem Volumen, für das kein menschliches Team dimensioniert war, schneller produziert, als dein Review-Prozess ihn aufnehmen kann.

Das Hauptrisiko von Dynamic Workflows ist, dass das Volumen die Verifikation überholt. Hunderte Agenten können an einem Tag mehr Änderungen erzeugen, als ein Team sinnvoll prüfen kann, sodass sich die Schranke davon, wie schnell man Code schreiben kann, dazu verschiebt, wie schnell man ihm vertrauen kann.

Drei Fallen sind es wert, eingeplant zu werden, bevor du das in einer Kunden-Codebasis aktivierst. Die erste ist Review-Schuld. Wenn ein Workflow ein großes koordiniertes Change-Set abliefert, ist die Versuchung, der Selbstverifikation der Runtime zu vertrauen und zu mergen. Selbstverifikation fängt mechanische Fehler ab — fehlschlagende Tests, kaputte Builds — aber sie fängt keine korrekt aussehende Umsetzung der falschen Anforderung ab. Dieses Urteil muss weiterhin deins sein.

Die zweite ist Observability. Hintergrund-Sessions laufen unabhängig von deinem Chat, das ist der Sinn, aber es bedeutet auch, dass ein Workflow lange werkeln kann, bevor du merkst, dass er aus dem Ruder lief. Die Muster, die rund um Hintergrund-Agenten in Claude Code 2.1 entstehen, ähneln eher dem Betrieb langlaufender Dienste als dem Senden von Chat-Nachrichten — du willst Logging, Statusprüfungen und sauberes Herunterfahren, kein blindes Vertrauen (CallSphere). Zu wissen, wie man Sessions mit /sessions und /switch listet und fortsetzt, ist die Mindestlatte, nicht die Ziellinie.

Die dritte ist Kostenüberraschung. Ein Workflow, der bei einer Aufgabe, die es nicht brauchte, standardmäßig seine maximale Agentenzahl nutzt, verbrennt Budget ohne Mehrwert. Die kleinste Flotte zu wählen, die das Problem tatsächlich löst, ist sowohl eine Architektur- als auch eine Finanzentscheidung. Die Studios, die alle drei als zentrale Engineering-Anforderungen behandeln, nicht als nachträgliche Gedanken, sind die, die Dynamic Workflows reuelos in Produktion bringen.

FAQ

**Was sind Dynamic Workflows in Claude Code?** Dynamic Workflows sind JavaScript-Orchestrierungsskripte, die Claude für eine Aufgabe schreibt. Eine Hintergrund-Runtime führt viele Subagenten parallel aus, hält Zwischenzustände in Skriptvariablen und liefert ein verifiziertes, koordiniertes Ergebnis ([Claude Code Docs](https://code.claude.com/docs/en/workflows)).

Wie viele Subagenten kann ein Dynamic Workflow nutzen? Anthropic spricht von zehn bis hunderten parallelen Subagenten pro Session, und die Research Preview unterstützt Berichten zufolge bis zu 1.000 (Anthropic).

Wie unterscheiden sich Dynamic Workflows von Subagents und Agent Teams? Es sind drei eigenständige Primitive: Subagents für begrenzte Delegation, Agent Teams für persistente rollenbasierte Arbeit und Dynamic Workflows für Aufgaben, die mehr Agenten brauchen, als eine Konversation koordinieren kann (Ken Huang).

Welche Claude-Code-Version führte Dynamic Workflows ein? Claude Code 2.1.154, ausgeliefert am 28. Mai 2026, zusammen mit Claude Opus 4.8 (Classmethod).

Kosten Dynamic Workflows mehr? Können sie. Hunderte parallele Agenten erhöhen Durchsatz und Rechnung; die Einsparungen kommen daraus, die Agentenzahl an die Aufgabenstruktur anzupassen (CloudZero).

Das Fazit

Dynamic Workflows sind der erste echte Paradigmensprung in Claude Code seit den Subagents, weil die Orchestrierung jetzt im Code statt im Chat-Turn lebt. Die Teams, die damit gewinnen, werden nicht die sein, die die meisten Agenten starten — es werden die mit der Verifikationsdisziplin sein, dem zu vertrauen, was zurückkommt. Wenn du agentisches Coding skalierst und Orchestrierung auf Review-Gates statt auf blindem Durchsatz aufbauen willst, genau das ist die Engineering-Arbeit, die wir bei Context Studios machen.