Anthropic hat Claude Code Dynamic Workflows in die Research Preview gehoben, und die Schlagzeile ist schwer zu übersehen. Ein einzelner Lauf kann auf bis zu 1.000 Subagenten auffächern, davon 16 parallel, während ein JavaScript-Skript, das Claude selbst schreibt, die gesamte Orchestrierung übernimmt. Für Teams, die schon heute Mobile-, Automatisierungs- und Agentenprodukte ausliefern, schließt das die Lücke zwischen einem einzelnen Chat und einem echten Schwarm.
Die meisten Agentenläufe brechen heute nach ein paar Dutzend Schritten ab. Das Modell verliert den Plan, das Tool-Log sprengt das Kontextfenster, und eine lange Aufgabe endet still mit einem halben Ergebnis. Dynamic Workflows lösen das, indem sie die Schleife komplett aus dem Modell herausziehen. Claude liest die Aufgabe, schreibt ein JS-Skript mit dem Plan, und eine separate Runtime führt das Skript im Hintergrund aus, während die Sitzung reaktiv bleibt. Schleife, Verzweigung und Zwischenwerte leben in den Variablen des Skripts, nicht im Modellgedächtnis.
Die 30-Sekunden-Version
Was Claude Code Dynamic Workflows wirklich tun
Ein Dynamic Workflow ist ein kleines JavaScript-Programm. Claude erzeugt das Programm aus dem Prompt, die Runtime führt es aus, und jeder Funktionsaufruf im Skript kann einen Subagenten starten. Jeder Subagent bekommt ein eigenes Kontextfenster, eine Aufgabe und ein Tool-Set. Ergebnisse kommen als gewöhnliche JavaScript-Werte zurück, sodass das Eltern-Skript verzweigen, wiederholen, filtern und zusammenführen kann, ohne erneut durch das Modell zu gehen.
- Fan-out — bis zu 16 Subagenten laufen parallel, gedeckelt bei 1.000 pro Workflow.
- Verifizierung eingebaut — Agenten greifen ein Problem aus unabhängigen Winkeln an, andere widerlegen das Ergebnis, und die Schleife läuft weiter, bis die Antworten konvergieren.
- Hintergrund-Runtime — der Workflow läuft weiter, während die interaktive Claude-Code-Sitzung reaktiv bleibt.
- Drei Oberflächen — CLI, Desktop und die VS-Code-Erweiterung greifen auf dieselbe Workflow-Engine zu.
- Drei Clouds — läuft auf der Anthropic-API, Amazon Bedrock, Google Cloud Vertex AI und Microsoft Foundry.
Die Form ist der Punkt. Das Modell macht weiterhin das harte Denken, aber der Kontrollfluss ist ein Skript, das man lesen, bearbeiten und neu abspielen kann. Damit wird der gesamte Lauf nachvollziehbar, was bei einem langen Einzel-Prompt nie der Fall ist. Mehr Hintergrund zu dieser Ebene steht in unserem Beitrag zur Orchestrierungs-Ära des agentischen Programmierens.
Warum 1.000 Subagenten ein größeres Modell schlagen
Ein größeres Kontextfenster hilft einem Lauf, mehr Zustand zu halten. Ein Schwarm hilft einem Lauf, mehr Optionen zu testen. Das sind unterschiedliche Probleme. Dynamic Workflows erlauben dem Eltern-Agenten, eine Suche zu entwerfen, statt eine einzelne Antwort zu schreiben. Das verändert die Art von Arbeit, die ein Team an das Modell geben kann.
| Aufgabenform | Einzel-Prompt | Dynamic Workflow |
|---|---|---|
| Bug-Suche über 2.000 Dateien | Stichprobe, oft unvollständig | Ein Subagent pro Slice, Ergebnisse zusammengeführt |
| Framework-Migration | Manuelle Datei-für-Datei-Schleife | Parallele Rewrites mit Verifier-Pass |
| Recherche mit Gegenprüfung | Eine Antwort, kein Audit | Unabhängige Agenten, adversariale Prüfung |
| Security-Audit | Übersprungene Pfade, Drift | Begrenzter Scope pro Subagent, Beleglog |
| Lang laufendes Ops-Runbook | Bricht nach wenigen Schritten | Hintergrundlauf mit Checkpoint-State |
Der Bun-Port: 1.000 Subagenten in der Praxis
Der bisher öffentlichste Test der Dynamic Workflows ist der Port der Bun-Runtime von Zig nach Rust. Jarred Sumner nutzte einen Dynamic Workflow, um etwa 750.000 Zeilen Rust neu zu schreiben, wobei 99,8% der vorhandenen Testsuite weiter bestand, in elf Tagen vom ersten Commit bis zum Merge. Das ist keine Chat-mit-KI-Demo. Das ist ein Sprachport, der ein kleines Team normalerweise ein Quartal kostet, ausgeführt von einer einzelnen Person mit einem Workflow, der sich selbst überwacht hat.
Bis zu 16 Subagenten parallel. Bis zu 1.000 Subagenten pro Lauf. Lesbares JS-Skript als Plan.
Das Interessante ist nicht die Zeilenzahl. Es ist, dass der Verifizierungsschritt gehalten hat. Der Workflow konnte eigene Rewrites gegen die Testsuite widerlegen, fehlgeschlagene Slices erneut versuchen und nur den finalen konvergenten Diff dem menschlichen Reviewer zeigen. Diese Schleife bekommt man aus keinem langen Einzel-Prompt heraus, egal wie viele Token man ihm gibt.
Wo das in den Mobile- und Automatisierungs-Stack passt
Bei Halmob betrachten wir jede neue Agentenfunktion mit denselben drei Fragen auf unserer Startseite: überlebt sie auf einem Handy, passt sie in eine bestehende Automatisierung, und bleibt sie beobachtbar. Dynamic Workflows beantworten alle drei sinnvoll, aber die Antwort lautet nicht "überall einsetzen".
Das Handy bleibt die Freigabe-Oberfläche
Ein Lauf mit 1.000 Subagenten ist nichts, was auf einem Handy laufen sollte. Es ist etwas, das ein Handy freigeben, beobachten und stoppen sollte. Kombiniert man Dynamic Workflows mit dem Mobile-Orchestrierungsmuster aus Hermes Workspace Mobile- und Agenten-Orchestrierung, wird das Handy zur Operator-Konsole, nicht zur Runtime.
n8n und der Schwarm liegen auf verschiedenen Ebenen
n8n löst aus, gated und routet. Dynamic Workflows fächern die eigentliche Arbeit auf und führen sie zusammen. Die richtige Form ist meistens ein n8n-Trigger, der eine eingegrenzte Aufgabe an einen Dynamic Workflow übergibt und auf das konvergierte Ergebnis wartet, bevor es weitergeschickt wird. Dieselbe Schichtung beschreiben wir auch im Beitrag zu Kimi K2.6 Agent-Schwärmen.
Ein Conductor hilft trotzdem
Dynamic Workflows orchestrieren Claude-Subagenten. Reale Deployments mischen Modelle, Tools und Menschen. Eine höhere Conductor-Ebene leitet Aufgaben an die richtige Engine, genau die Rolle aus Sakana Conductor Multi-Agenten-Orchestrierung. Dynamic Workflows werden zu einer der Engines, nicht zum ganzen Stack.
So startest du, ohne ein Monatsbudget zu verbrennen
- 1Aktualisiere Claude Code auf v2.1.154 oder höher und schalte Dynamic Workflows ein. In Max und Team ist es standardmäßig an. In Enterprise aktiviert ein Admin. In Pro schaltest du es manuell ein. Die offizielle Claude-Code-Workflows-Dokumentation nennt das genaue Flag.
- 2Wähle eine Aufgabe, die heute bei etwa fünfzig Tool-Aufrufen oder einer Stunde stehenbleibt. Codebasis-Audits und Migrationen sind die günstigsten Stellen, um den Wert zu spüren.
- 3Starte mit einem Budget von 50 Subagenten und 4 parallel. Spring nicht auf 1.000. Ein kleiner Schwarm mit klaren Grenzen lehrt in der ersten Woche mehr als ein großer, den niemand prüfen kann.
- 4Sichere das Skript. Der ganze Reiz dieser Idee ist, dass der Plan eine Datei ist. Commit, Diff, Teil der Automatisierungsquelle.
- 5Verdrahte den Lauf mit deinem bestehenden Review-Prozess. Der Workflow kann sich selbst widerlegen, aber ein Mensch sollte den finalen Diff vor dem Merge sehen.
Risiken und Leitplanken
Drei Kosten, die du einplanen solltest
- Token-Verbrauch skaliert mit dem Schwarm. Setze eine Obergrenze pro Workflow, bevor er unbeaufsichtigt läuft.
- Determinismus ist nur teilweise gegeben. Das Skript ist reproduzierbar, jeder Subagent-Aufruf bleibt ein Modell-Aufruf. Behandle den Workflow als Verifier, nicht als Beweis.
- Tool-Wirkradius wächst mit Parallelität. Sechzehn Agenten an derselben Schreib-API können echten Schaden anrichten. Scope Tools pro Subagent, nicht pro Workflow.
- Auditierbarkeit braucht bewusstes Logging. Das Skript ist lesbar, die Subagent-Begründung nicht. Logge Prompt, Ergebnis und das entscheidende Indiz an jeder Verzweigung.
Fazit
Claude Code Dynamic Workflows machen das Orchestrierungsskript zu einem lesbaren Artefakt und den Schwarm zur Standardoption. Für Mobile-, Automatisierungs- und Agenten-Teams schließt das die Lücke zwischen einem einzelnen Prompt und einem realen Langläufer. Der richtige nächste Schritt ist nicht, alles auf einen 1.000-Subagenten-Workflow zu portieren. Es ist, eine Aufgabe zu wählen, die heute im Großen scheitert, sie in einen kleinen Dynamic Workflow zu wickeln und einen menschlichen Review am Konvergenzpunkt zu platzieren.
Wer die Agentenschicht darunter noch sortiert, findet die Bausteine im OpenClaw-101-Leitfaden. Danach lässt sich besser entscheiden, welcher dieser Bausteine ein eigenes Skript verdient.