Dutzende bis Hunderte von Sub-Agenten gleichzeitig mit den Dynamic Workflows von Claude Code ausführen
Inhaltsverzeichnis
Haben Sie sich jemals gedacht: „Das schaffe ich nicht in einem einzigen Chat", wenn Sie Claude mit einer systemweiten Fehlersuche oder einer Migration über Hunderte von Dateien beauftragt haben? Die Arbeitsweise, bei der Claude Aufgaben nacheinander abarbeitet, hat zwangsläufig eine Obergrenze für den Bereich, den sie gleichzeitig erfassen kann. Das Kontextfenster ist begrenzt, und je mehr Informationen untersucht werden, desto eher werden die anfänglichen Erkenntnisse verdrängt.
Neu hinzugekommen sind die Dynamic Workflows (dynamische Workflows), die wir Ihnen heute vorstellen. Claude schreibt spontan ein Orchestrierungsskript für die jeweilige Aufgabe und lässt basierend darauf Dutzende bis Hunderte von Sub-Agenten parallel laufen, um große Aufgaben aufzuteilen und zu erledigen. Zudem stoppt die Sitzung während der Ausführung nicht, sodass wir an anderen Aufgaben weiterarbeiten können.
Derzeit befinden sie sich im Status einer „Research Preview" (Forschungsvorschau) und sind ab Claude Code v2.1.154 verfügbar. Es handelt sich noch um eine Funktion in der Entwicklung, aber das Konzept an sich unterscheidet sich ein wenig von bisherigen Sub-Agenten und ist sehr interessant. Schauen wir uns den Mechanismus genauer an.
Was sind Dynamic Workflows?
Kurz gesagt sind Dynamic Workflows „JavaScript zur Orchestrierung von Sub-Agenten in großem Maßstab".
Bisher gab es in Claude Code bereits Mechanismen, um Aufgaben an eine andere Claude-Instanz (Sub-Agent) auszulagern. Das Neue an Dynamic Workflows ist, dass Claude die Planung selbst - also „welcher Agent in welcher Reihenfolge wie oft ausgeführt wird" - als Code ausschreibt.
Der Ablauf ist wie folgt:
- Sie beschreiben verbal, was Sie tun möchten.
- Claude schreibt ein Orchestrierungsskript für diese Aufgabe.
- Eine dedizierte Laufzeitumgebung (Runtime) führt dieses Skript im Hintergrund aus und lässt Sub-Agenten parallel arbeiten.
- Zwischenergebnisse werden abgeglichen und verifiziert, und nur die endgültige Antwort wird an uns zurückgegeben.
Der entscheidende Punkt ist, dass die Planung nicht in Claudes Kopf (Kontext) bleibt, sondern in eine sichtbare Form als Skript gegossen wird. Das Skript ist lesbar, und wenn es Ihnen gefällt, können Sie es speichern und denselben Ablauf immer wieder ausführen. Da Zwischenergebnisse in den Variablen des Skripts gespeichert werden, kehrt nur das Endergebnis in Claudes Kontext zurück. Genau deshalb ist es möglich, Aufgaben in einer Größenordnung anzugehen, die eine einzelne Konversation sprengen würde.
Geeignet sind sie zum Beispiel für folgende Szenarien:
- Fehlersuche über die gesamte Codebasis hinweg.
- Migrationen, die Hunderte von Dateien betreffen (Framework-Wechsel, API-Deprecations, Sprach-Portierungen etc.).
- Recherchen, bei denen mehrere Informationsquellen gegeneinander geprüft werden sollen.
- Entwürfe für komplexe Architekturen, die aus verschiedenen Blickwinkeln skizziert und verglichen werden sollen.
Unterschied zu Sub-Agenten und Skills
Claude Code verfügt bereits über mehrere Möglichkeiten, mehrstufige Aufgaben zu bewältigen: Sub-Agenten, Skills und nun die Workflows. Da dies verwirrend sein kann, ordnen wir sie nach der Achse „Wer steuert den Ablauf (Plan)?" ein.
| Sub-Agenten | Skills | Workflows | |
|---|---|---|---|
| Wesen | Von Claude gestartete Worker | Anweisungen, denen Claude folgt | Von Claude geschriebene, automatisch ausgeführte Skripte |
| Wer entscheidet den nächsten Schritt? | Claude (pro Turn) | Claude (gemäß Anweisung) | Das Skript |
| Speicherort für Zwischenergebnisse | Claudes Kontext | Claudes Kontext | Variablen im Skript |
| Wiederverwendbarkeit | Definition des Workers | Inhalt der Anweisung | Die Orchestrierung selbst |
| Umfang | Einige pro Turn | Ähnlich wie Sub-Agenten | Dutzende bis Hunderte pro Ausführung |
| Bei Unterbrechung | Turn muss neu gestartet werden | Turn muss neu gestartet werden | Fortsetzung innerhalb derselben Sitzung möglich |
Bei Sub-Agenten und Skills ist Claude selbst der Orchestrator. In jedem Turn wird entschieden: „Was mache ich als Nächstes?", und alle Ergebnisse kehren in Claudes Kontext zurück. Im Gegensatz dazu übernimmt bei Workflows das Skript die Steuerung von Schleifen, Verzweigungen und der Speicherung von Zwischenergebnissen. Durch die Verlagerung der Planung in Code ist es nicht nur möglich, die Anzahl der Agenten zu erhöhen, sondern auch wiederverwendbare Qualitätsmuster einzubauen.
Man kann beispielsweise mehrere unabhängige Agenten die Entdeckungen der jeweils anderen kritisch prüfen lassen, bevor ein Bericht erstellt wird, oder einen Entwurf aus verschiedenen Perspektiven skizzieren lassen, um sie abzuwägen. Das macht das Ergebnis zuverlässiger als bei einer einmaligen Verarbeitung.
Unterschied zu Agent Teams
Bisher haben wir Sub-Agenten und Skills verglichen, aber es gibt noch einen weiteren Mechanismus, der Workflows am nächsten kommt, wenn es darum geht, „mehrere Agenten parallel zu bündeln": Agent Teams. Wer bereits gewohnt ist, Aufgaben wie „Bilde ein Agent Team und lass jeden diesen Aspekt untersuchen" zu stellen, wird sich fragen, wie sie sich von Workflows unterscheiden.
Agent Teams sind ein System, bei dem eine leitende Claude-Sitzung mehrere „Teammitglieder" startet, die über eine gemeinsame Aufgabenliste und Nachrichten kooperieren. Die Teammitglieder sind eigenständige Claude-Code-Sitzungen mit jeweils eigenem Kontext, die sich über eine Mailbox direkt Nachrichten schicken können. Zudem können wir selbst direkt mit einzelnen Teammitgliedern sprechen, ohne über den Leiter zu gehen, um die Richtung zwischendurch zu korrigieren. Agent Teams sind eine experimentelle Funktion und standardmäßig deaktiviert. Sie können durch Aktivieren von CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS genutzt werden (ab Claude Code v2.1.32).
Obwohl beide „Agenten parallel laufen lassen", ist ihr Charakter sehr unterschiedlich.
| Agent Teams | Dynamic Workflows | |
|---|---|---|
| Status | Experimentell (standardmäßig aus, ab v2.1.32) | Research Preview (ab v2.1.154) |
| Wer steuert den Ablauf? | Leitender Claude (entscheidet pro Turn) | Skript (codierter Kontrollfluss) |
| Zusammenarbeit zwischen Agenten | Direkte Nachrichten über Aufgabenliste und Mailbox | Kein direkter Austausch; Skript bündelt Ergebnisse |
| Eingriff während der Ausführung | Jederzeit möglich, Mitglieder direkt anzusprechen | Keine Benutzereingaben währenddessen (nur Berechtigungsanfragen) |
| Empfohlener Umfang | 3-5 Mitglieder empfohlen | Dutzende bis Hunderte, insgesamt max. 1.000 |
| Fortsetzung und Wiederverwendung | Laufende Mitglieder werden bei Sitzungsneustart nicht wiederhergestellt | Fortsetzung in derselben Sitzung möglich. Ablauf als /Befehl speicherbar |
Kurz gesagt: Agent Teams sind ein „spontan gebildetes, gesprächiges Team", während Dynamic Workflows eine „in Code gegossene, durchlaufende Pipeline" sind.
Wenn Sie möchten, dass Teammitglieder Hypothesen gegeneinander prüfen oder wenn Sie von der Seite rufen wollen: „Schau nicht dort, sondern hier", sind Agent Teams besser geeignet. Offiziell werden sie für kollaborative und explorative Aufgaben empfohlen, wie z. B. PR-Reviews nach verschiedenen Gesichtspunkten oder die Suche nach der Ursache eines Bugs durch gegenseitiges Widerlegen von Hypothesen. Die empfohlene Teamgröße liegt bei etwa 3 bis 5 Mitgliedern.
Wenn hingegen die zu verteilende Arbeit so umfangreich ist, dass man sie nicht einzeln im Blick behalten kann, wenn man jedes Mal exakt denselben Ablauf wünscht oder Ergebnisse mechanisch kreuzprüfen möchte, schlägt die Stunde der Workflows. Da das Skript die Kontrolle hat, kann man während der Ausführung nicht korrigierend eingreifen, aber dafür können Dutzende bis Hunderte von Agenten reibungslos koordiniert werden. Ein bewährter Ablauf kann als /Befehl gespeichert und beliebig oft reproduziert werden.
Denken Sie an Aufgaben, bei denen Sie normalerweise in Skills oder Prompts schreiben: „Bilde ein Agent Team...". Wenn es sich dabei um Abläufe handelt, die Sie jedes Mal gleich durchführen möchten oder die zu groß sind, um ständig dabei zu sein, ist es sinnvoll, sie in einen Workflow zu überführen und als Skript zu speichern. Das verbessert die Reproduzierbarkeit und Skalierbarkeit. Aufgaben, die in einer Phase der Abstimmung und gemeinsamen Erarbeitung stecken, sind weiterhin bei Agent Teams besser aufgehoben. Man sollte beide nicht als Ersatz füreinander sehen, sondern sie je nach Art der Aufgabe wählen.
Zuerst mit /deep-research ausprobieren
Genug der Theorie, am besten probiert man es einfach aus. Um schnell ein Gefühl dafür zu bekommen, empfiehlt sich der in Claude Code integrierte Workflow /deep-research.
Dieser Workflow untersucht eine Frage aus verschiedenen Blickwinkeln per Web-Suche, gleicht die gefundenen Quellen gegeneinander ab und erstellt einen Bericht mit Quellenangaben.
/deep-research Was hat sich am Permission-Modell von Node.js zwischen v20 und v22 geändert?
Nach dem Ausführen fragt Claude Code, ob dieser Workflow ausgeführt werden darf. Wenn Sie Yes wählen, beginnt die Untersuchung im Hintergrund. Ihre aktuelle Sitzung bleibt frei, sodass Sie währenddessen an etwas anderem arbeiten können.
Wenn Sie den Zwischenstand sehen möchten, führen Sie /workflows aus.
/workflows
Es erscheint eine Liste der laufenden und abgeschlossenen Workflows. Wählen Sie einen mit den Pfeiltasten aus und drücken Sie Enter, um die Fortschrittsansicht zu öffnen. Für jede Phase werden die Anzahl der aktiven Agenten, der Token-Verbrauch und die verstrichene Zeit angezeigt. Sie können tiefer in die Phasen eintauchen, um zu sehen, was die einzelnen Agenten gerade untersuchen.
Sobald die Untersuchung abgeschlossen ist, kehrt der Bericht in die Sitzung zurück. Es wird explizit angegeben, welche Behauptung aus welcher Quelle stammt, und widersprüchliche oder nicht verifizierte Aussagen werden vorab aussortiert. Beachten Sie, dass /deep-research eine Umgebung voraussetzt, in der die Web-Suche (WebSearch-Tool) verfügbar ist.
Eigene Aufgaben in Workflows umwandeln
Wenn Sie ein Gefühl für die integrierten Workflows bekommen haben, können Sie eigene Aufgaben angehen. Dafür gibt es im Wesentlichen zwei Wege.
„workflow" in den Prompt schreiben
Der einfachste Weg ist, das Wort workflow irgendwo in Ihren Prompt einzubauen. Ohne die globalen Sitzungseinstellungen zu ändern, wird diese eine Anfrage als Workflow ausgeführt.
Prüfe mit einem workflow alle API-Endpunkte unter src/routes/ auf fehlende Authentifizierungs-Checks.
Wenn Sie dies schreiben, hebt Claude Code das Wort workflow während der Eingabe hervor und erstellt ein Workflow-Skript für die Aufgabe, anstatt sie direkt im Turn zu bearbeiten.
Sollte workflow reagieren, obwohl Sie es nicht beabsichtigt haben, können Sie es mit Alt+W für diesen Prompt ignorieren. Das ist nützlich, wenn Sie das Wort nur im Fließtext verwenden, z. B. „Lass uns den Workflow besprechen".
Claude mit /effort ultracode entscheiden lassen
Der zweite Weg ist die Nutzung des neuen Effort-Levels (Denkintensität) namens ultracode.
/effort ultracode
ultracode kombiniert die Schlussfolgerungsstärke von xhigh mit der automatischen Workflow-Orchestrierung. Wenn dies aktiviert ist, entscheidet Claude selbst, ob eine Aufgabe es wert ist, in einen Workflow umgewandelt zu werden, ohne dass Sie es explizit verlangen. Eine einzige Anfrage kann in mehrere Workflows aufgeteilt werden - zum Beispiel einen Workflow zum Verständnis des Codes, einen für die Änderungen und einen zur Verifizierung.
Dies erhöht jedoch den Token-Verbrauch für alle Aufgaben in der Sitzung und nimmt mehr Zeit in Anspruch. ultracode ist nur für die aktuelle Sitzung aktiv und wird bei einer neuen Sitzung zurückgesetzt. Wenn Sie zu normalen Aufgaben zurückkehren, sollten Sie den Level mit /effort wieder zurückstellen. Der Standardwert für viele Modelle ist high, aber für tiefere Schlussfolgerungen können Sie xhigh dauerhaft nutzen (bei Opus 4.7 ist xhigh ohnehin Standard). Beachten Sie, dass ultracode nur für Modelle verfügbar ist, die xhigh unterstützen; bei anderen Modellen erscheint es nicht im /effort-Menü.
Genehmigung und Berechtigungen vor der Ausführung
Da Workflows viele Agenten starten, laufen sie nicht einfach ungefragt los, sondern verlangen vorab eine Genehmigung. Im CLI werden die geplanten Phasen zusammen mit folgenden Optionen angezeigt:
- Yes, run it -- Sofort ausführen.
- Yes, and don't ask again for
<name>in<path>-- Ausführen und für diesen Workflow in diesem Projekt künftig nicht mehr nachfragen. - View raw script -- Den Inhalt des Skripts lesen, bevor man entscheidet.
- No -- Abbrechen.
Mit Strg+G können Sie das Skript im Editor öffnen, und mit Tab können Sie den Prompt vor der Ausführung anpassen. Wenn Sie unsicher sind, schauen Sie ruhig hinein, bevor Sie zustimmen.
Ob der Bestätigungsdialog erscheint, hängt vom Berechtigungsmodus ab.
| Berechtigungsmodus | Zeitpunkt der Nachfrage |
|---|---|
| Default, accept edits | Jedes Mal (außer bei Workflows, für die „künftig nicht mehr nachfragen" gewählt wurde) |
| Auto | Nur beim ersten Mal. Wenn „Yes" gewählt wird, wird die Zustimmung in den Benutzereinstellungen gespeichert und künftig nicht mehr gefragt. Bei aktivem ultracode entfällt die Nachfrage oft ganz. |
Bypass permissions, claude -p, Agent SDK | Sofortige Ausführung ohne Nachfrage |
Wichtig zu wissen: Dieser Dialog steuert nur die „Bestätigung beim Start". Die vom Workflow erzeugten Sub-Agenten laufen unabhängig vom Modus Ihrer Hauptsitzung immer im acceptEdits-Modus und übernehmen die konfigurierte Tool-Allowlist. Dateibearbeitungen werden automatisch genehmigt.
Shell-Befehle, Web-Abrufe oder MCP-Tools, die nicht auf der Allowlist stehen, können jedoch während der Ausführung eine Bestätigung verlangen. Um zu verhindern, dass ein lang laufender Workflow dadurch unterbrochen wird, sollten Sie benötigte Befehle vorab zur Allowlist hinzufügen.
Fortschritt in der /workflows-Ansicht verfolgen
Wie bereits erwähnt, ist die /workflows-Ansicht die Kommandozentrale. Hier können Sie die im Hintergrund laufenden Arbeiten detailliert überwachen. Hier sind die wichtigsten Tasten für die Fortschrittsansicht:
| Taste | Aktion |
|---|---|
↑ / ↓ | Phase oder Agent auswählen |
Enter oder → | In die ausgewählte Phase eintauchen oder einen Agenten öffnen, um Prompts, letzte Tool-Aufrufe und Ergebnisse zu lesen |
Esc | Eine Ebene zurückgehen |
p | Ausführung pausieren / fortsetzen |
x | Ausgewählten Agenten stoppen (stoppt den gesamten Workflow, wenn der Fokus auf der Gesamtausführung liegt) |
r | Ausgewählten laufenden Agenten neu starten |
s | Das Skript der Ausführung als Befehl speichern (siehe unten) |
In dem Task-Panel unter der Eingabezeile sehen Sie zudem eine einzeilige Zusammenfassung des Fortschritts. Mit der Pfeiltaste nach unten können Sie den Fokus darauf legen und mit Enter Details einblenden.
Workflows speichern und wiederverwenden
Wenn eine Ausführung genau so funktioniert hat, wie Sie es wollten, können Sie das Skript als Befehl speichern. Für Routineaufgaben wie „Review bei jedem neuen Branch" können Sie so immer dieselbe Orchestrierung aufrufen.
Wählen Sie in /workflows die gewünschte Ausführung aus und drücken Sie s. Im Speicherdialog können Sie mit Tab zwischen zwei Speicherorten wählen:
.claude/workflows/(im Projekt) -- Wird mit allen geteilt, die das Repository klonen.~/.claude/workflows/(im Home-Verzeichnis) -- In allen Projekten verfügbar, aber nur für Sie sichtbar.
Nach dem Speichern mit Enter können Sie den Workflow in künftigen Sitzungen mit /<name> aufrufen. Er erscheint dann auch in der Autovervollständigung neben den integrierten Workflows. Es ist sinnvoll, Team-Standards im Projekt und persönliche Werkzeuge im Home-Verzeichnis zu organisieren. Falls ein Projekt-Workflow und ein persönlicher Workflow denselben Namen haben, hat der Projekt-Workflow Vorrang.
Diese Eigenschaft, Workflows zu speichern und zu teilen, hilft (ähnlich wie Skills und Hooks) dabei, Claude Code nahtlos in den eigenen Entwicklungsfluss zu integrieren.
Funktionsweise und Einschränkungen
Ein kurzer Blick unter die Haube: Die Skripte werden von einer sogenannten „Runtime" ausgeführt. Man kann sie sich als einen Mechanismus vorstellen, der das Skript unabhängig von der eigentlichen Claude-Hauptinstanz im Hintergrund vorantreibt. Diese Runtime führt das Skript in einer isolierten Umgebung aus, die von Ihrer Konversation getrennt ist. Zwischenergebnisse werden nicht in Claudes Kontext, sondern in den Variablen des Skripts gehalten, und die Runtime protokolliert die Ergebnisse jedes Agenten. Dank dieser Protokollierung kann ein gestoppter Workflow innerhalb derselben Sitzung fortgesetzt werden.
Dabei unterliegt die Runtime einigen Einschränkungen:
| Einschränkung | Grund |
|---|---|
| Keine Benutzereingaben während der Ausführung | Unterbrechungen erfolgen nur für Berechtigungsanfragen der Agenten. Wenn Sie schrittweise Genehmigungen wünschen, teilen Sie die Phasen in separate Workflows auf. |
| Workflow selbst kann nicht direkt auf Dateien oder Shell zugreifen | Das Lesen/Schreiben und Ausführen von Befehlen übernehmen die Agenten; das Skript koordiniert diese lediglich. |
| Maximal 16 gleichzeitig laufende Agenten (weniger auf Maschinen mit wenigen CPU-Kernen) | Um den lokalen Ressourcenverbrauch zu begrenzen. |
| Maximal 1.000 Agenten pro Ausführung | Um Amok laufende Schleifen zu verhindern. |
Wenn Sie einen gestoppten Workflow fortsetzen, geben bereits abgeschlossene Agenten ihre gecachten Ergebnisse zurück, und der Rest wird an der entsprechenden Stelle fortgesetzt. Dies funktioniert jedoch nur innerhalb derselben Claude-Code-Sitzung. Wenn Sie Claude Code während eines laufenden Workflows beenden, muss er in der nächsten Sitzung von vorne beginnen.
Kosten und Modelle
Da Workflows viele Agenten starten, können sie pro Ausführung deutlich mehr Token verbrauchen, als wenn man dieselbe Aufgabe innerhalb einer Konversation erledigt. In der offiziellen Anleitung heißt es dazu: „Leistungsstark, kann aber teuer sein. Da Token schnell verbraucht werden, fangen Sie bitte mit Aufgaben mit begrenztem Umfang an, um ein Gefühl dafür zu bekommen."
Die Ausführung wird wie jede andere Sitzung auf das Nutzungsvolumen Ihres Plans und die Rate-Limits angerechnet. Sie können einen Workflow jedoch jederzeit über /workflows stoppen, wobei die bis dahin abgeschlossene Arbeit nicht verloren geht. Wenn Sie das Gefühl haben, dass es aus dem Ruder läuft, halten Sie ihn einfach an.
Zum Thema Modelle: Die einzelnen Agenten innerhalb eines Workflows nutzen standardmäßig das Modell Ihrer aktuellen Sitzung, sofern das Skript keine bestimmte Phase einem anderen Modell zuweist. Daher:
- Wenn Sie für Routineaufgaben normalerweise auf ein kleineres Modell wechseln, prüfen Sie vor einer großen Ausführung Ihr
/model. - Geben Sie bei der Aufgabenstellung mit an: „Nutze für Phasen, die kein starkes Modell erfordern, ein kleineres Modell".
Mit solchen kleinen Kniffen lassen sich die Kosten bis zu einem gewissen Grad kontrollieren. Fangen Sie klein an, zum Beispiel mit der Prüfung eines einzelnen Verzeichnisses, um ein Gefühl für den Token-Verbrauch in Ihrem Projekt zu bekommen.
Workflows deaktivieren
Ich persönlich sehe derzeit keinen Grund, diese Funktion zu deaktivieren, aber basierend auf der offiziellen Dokumentation gibt es folgende Möglichkeiten, falls sie nicht benötigt wird:
Um sie nur in Ihrer Umgebung zu deaktivieren:
- Deaktivieren Sie „Dynamic workflows" in
/config(bleibt über Sitzungen hinweg bestehen). - Setzen Sie
"disableWorkflows": truein~/.claude/settings.json. - Setzen Sie die Umgebungsvariable
CLAUDE_CODE_DISABLE_WORKFLOWS=1beim Start.
Um sie für eine gesamte Organisation zu deaktivieren, kann in den Managed Settings "disableWorkflows": true festgelegt oder der Schalter auf der Administrator-Seite von Claude Code genutzt werden. Nach der Deaktivierung sind die Befehle für integrierte Workflows nicht mehr verfügbar, das Schlüsselwort workflow reagiert nicht mehr und ultracode verschwindet aus dem /effort-Menü.
Beispiele früherer Nutzer
Abschließend möchte ich einige Beispiele von Personen vorstellen, die Dynamic Workflows bereits genutzt haben (basierend auf offiziellen Blogs). Auch wenn dies nicht meine eigenen Erfahrungen sind, vermitteln sie ein Gefühl für die Dimensionen.
Besonders beeindruckend ist der Fall von Jarred Sumner, dem Schöpfer von Bun. Er nutzte Dynamic Workflows, um Bun von Zig nach Rust zu portieren. Dabei wurden ca. 750.000 Zeilen Rust-Code generiert, wobei 99,8 % der bestehenden Testsuite bestanden wurden - und das innerhalb von nur 11 Tagen. Dieses Beispiel zeigt, dass selbst Aufgaben wie Sprach-Portierungen über Tausende von Dateien hinweg von Anfang bis Ende durchgezogen werden können.
Andere Nutzer berichten davon, wie sie Dead Code oder Aufräumpotenziale aufgespürt haben, die von herkömmlichen statischen Analysen übersehen wurden, und so die Wartbarkeit verbessert haben. Aufgaben wie Framework-Wechsel oder API-Deprecations, die „zu groß für einen einzelnen Agenten, aber zu mühsam für manuelle Arbeit" sind, scheinen das ideale Einsatzgebiet zu sein.
Noch ein Wort zu den verfügbaren Plänen: Dynamic Workflows sind in allen kostenpflichtigen Plänen verfügbar. In den Plänen Max und Team sind sie standardmäßig aktiviert, in Pro können sie über /config eingeschaltet werden. In Enterprise erfolgt die Aktivierung durch den Administrator über Managed Settings. Zudem sind sie über die Anthropic API sowie auf Amazon Bedrock, Google Cloud Vertex AI und Microsoft Foundry verfügbar.
Fazit
Wir haben uns die Dynamic Workflows in Claude Code angesehen - von der Funktionsweise über die Anwendung bis hin zu Kostenüberlegungen. Hier die wichtigsten Punkte:
- Dynamic Workflows sind von Claude spontan geschriebene Orchestrierungsskripte, bei denen eine Runtime Dutzende bis Hunderte von Sub-Agenten parallel koordiniert. Verfügbar als Research Preview ab v2.1.154.
- Während bei Sub-Agenten und Skills Claude die Planung übernimmt, verlagern Workflows die Planung in Code. Zwischenergebnisse landen in Skriptvariablen, sodass nur das Fazit in Claudes Kontext zurückkehrt.
- Obwohl beide Agenten parallel laufen lassen, unterscheiden sich Agent Teams (interaktive Zusammenarbeit) und Workflows (codierte, automatisierte Abläufe) in ihrem Charakter. Für Beratung und Exploration eignet sich Ersteres, für Umfang und Reproduzierbarkeit Letzteres.
- Starten Sie am besten mit dem integrierten
/deep-research, um ein Gefühl zu bekommen. Eigene Aufgaben starten Sie entweder durch das Wortworkflowim Prompt oder indem Sie Claude mit/effort ultracodedie Entscheidung überlassen. - Über die
/workflows-Ansicht können Sie Fortschritte prüfen, pausieren, stoppen und speichern. Bewährte Abläufe lassen sich als/<name>-Befehl speichern. - Da viele Agenten aktiv sind, steigt der Token-Verbrauch. Es empfiehlt sich, mit kleinen Scopes zu testen und bei Bedarf Modelle gezielt zu wählen.
Die Frage, wie man Aufgaben delegiert, die „zu groß für einen einzigen Chat" sind, ist ein zentrales Thema bei der praktischen Nutzung von KI-Agenten. Dynamic Workflows bieten hier eine Antwort: „Mache die Planung selbst zu Code, der lesbar, reproduzierbar und parallel ausführbar ist." Auch wenn es noch eine Research Preview ist - probieren Sie es doch einfach mal für eine kleine Code-Prüfung oder Recherche aus.