← Alle Playbooks
Playbook· build

Dynamic Workflows in Claude Code, dein erstes orchestriertes Multi-Agent-Skript

Was Dynamic Workflows sind, wann du sie statt Subagents nimmst und wie du in einer Sitzung deinen ersten Workflow startest, beobachtest, speicherst und im Griff behaltest.

Seit dem Opus-4.8-Release kann Claude Code etwas, das vorher fehlte. Du beschreibst eine große Aufgabe, und Claude schreibt dir nicht nur die Antwort, sondern ein JavaScript-Skript das im Hintergrund dutzende Subagents orchestriert. Das heißt Dynamic Workflows, ist seit Version 2.1.154 verfügbar und steckt noch in der Research Preview. Ich zeig dir in 20 Minuten wie du deinen ersten Workflow laufen lässt, ohne dass dir die Token-Rechnung explodiert. Wir bauen das hier vorsichtig auf, erst der eingebaute Workflow zum Zuschauen, dann ein eigener.

Schritt 1, pruef deine Voraussetzungen

Dynamic Workflows brauchen Claude Code v2.1.154 oder neuer. Tipp claude --version in dein Terminal und schau nach. Wenn du älter bist, update zuerst, sonst taucht der ganze Mechanismus gar nicht auf.

Verfügbar sind Workflows auf allen Paid-Plans, über die Anthropic API und auf Amazon Bedrock, Google Cloud Vertex AI und Microsoft Foundry. Wenn du auf dem Pro-Plan bist, sind sie nicht automatisch an. Du schaltest sie über die Zeile "Dynamic workflows" in /config ein. Auf Max und den größeren Plans laufen sie direkt.

Mach diesen Check ernsthaft. Ich hab beim ersten Versuch zehn Minuten gesucht warum das Keyword nichts tut, und es lag schlicht an einer alten Version.

Schritt 2, versteh wann ein Workflow das richtige Werkzeug ist

Claude Code hat vier Wege eine mehrstufige Aufgabe zu erledigen. Subagents, Skills, Agent Teams und Workflows. Der Unterschied ist nur einer, nämlich wer den Plan hält.

Bei Subagents, Skills und Agent Teams ist Claude der Dirigent. Es entscheidet Zug um Zug was als nächstes passiert, und jedes Zwischenergebnis landet in seinem Kontextfenster. Ein Workflow verschiebt den Plan in Code. Das Skript hält die Schleife, die Verzweigungen und die Zwischenergebnisse selbst, und in Claudes Kontext landet nur die fertige Antwort.

Greif zum Workflow wenn eine Aufgabe mehr Agents braucht als eine einzige Unterhaltung koordinieren kann. Ein Bug-Sweep über das ganze Repo. Eine Migration über 500 Dateien. Eine Recherche-Frage bei der Quellen gegeneinander gegengecheckt werden sollen. Oder ein schwieriger Plan, den du aus mehreren unabhängigen Blickwinkeln entworfen haben willst bevor du dich festlegst. Für drei delegierte Tasks pro Zug bleibst du bei Subagents, dafür ist ein Workflow Overkill.

Schritt 3, lauf zuerst den eingebauten /deep-research Workflow

Bevor du selbst was baust, schau dir an wie sich ein Workflow anfühlt. Claude Code bringt /deep-research als fertigen Workflow mit. Der fächert Websuchen über mehrere Blickwinkel auf, holt und kreuzt die Quellen gegeneinander, stimmt über jeden Claim ab und gibt dir am Ende einen Bericht mit Zitaten zurück.

/deep-research What changed in the Node.js permission model between v20 and v22?

Claude Code fragt jetzt ob es den Workflow ausführen darf. Wähl Yes. Der Run startet im Hintergrund, deine Sitzung bleibt frei. Du musst nicht warten und Daumen drehen, du kannst weiterarbeiten während die Agents im Hintergrund laufen. Wichtig dabei, /deep-research braucht das WebSearch-Tool, sonst hat es keine Quellen.

Schritt 4, schau dem Run zu mit /workflows

Tipp /workflows und du siehst alle laufenden und fertigen Workflows. Pfeiltasten zum Auswählen, Enter zum Reingehen.

/workflows

Die Fortschritts-Ansicht zeigt dir jede Phase mit Agent-Anzahl, Token-Summe und vergangener Zeit. Du kannst mit Enter in eine Phase reinbohren und sehen was jeder einzelne Agent gefunden hat. Die wichtigsten Tasten stehen in der Fußzeile, ein paar lohnen sich zu merken. p pausiert oder setzt den Run fort. x stoppt einen einzelnen Agent oder den ganzen Workflow wenn der Fokus auf dem Run liegt. r startet einen hängenden Agent neu. s speichert das Skript des Runs als eigenen Command, dazu kommen wir noch.

Schritt 5, lass Claude einen Workflow für deine Aufgabe schreiben

Jetzt dein eigener Workflow. Der einfachste Weg, du packst das Keyword ultracode in deinen Prompt. Dann schreibt Claude ein Skript für die Aufgabe statt sie Zug um Zug abzuarbeiten.

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Claude Code hebt das Keyword in deiner Eingabe hervor und legt los. In eigenen Worten geht es auch, "use a workflow" oder "run a workflow" behandelt Claude als dieselbe Zustimmung. Kleiner Hinweis zur Version, vor v2.1.160 war das wörtliche Trigger-Keyword workflow, natuerlichsprachige Anfragen funktionieren in beiden Versionen. Wenn du das Keyword versehentlich getippt hast, druck Option und W auf dem Mac oder Alt und W auf Windows und Linux, dann verschwindet die Hervorhebung für diesen Prompt.

Wer dauerhaft im Workflow-Modus arbeiten will, setzt /effort ultracode. Das kombiniert xhigh Reasoning mit automatischer Orchestrierung, Claude plant dann für jede größere Aufgabe der Sitzung selbst einen Workflow. Das frisst aber spürbar mehr Tokens und dauert länger. Ich geh mit /effort high wieder runter sobald ich zurück bei Routine-Arbeit bin.

Schritt 6, nick den Plan ab bevor er läuft

In der CLI zeigt dir Claude vor jedem Run die geplanten Phasen und ein paar Optionen. Yes startet. Yes und nicht mehr fragen merkt sich deine Zustimmung für genau diesen Workflow in diesem Projekt. View raw script zeigt dir das Skript bevor du entscheidest, Ctrl+G öffnet es direkt in deinem Editor. Mit Tab kannst du den Prompt noch anpassen bevor es losgeht.

Lies das Skript beim ersten Mal wirklich. Ein Workflow ist Code den Claude geschrieben hat, und du willst sehen was er über deine Dateien laufen lässt bevor er es tut. Die Subagents die ein Workflow spawnt laufen übrigens immer im acceptEdits-Modus und erben deine Tool-Allowlist, unabhängig vom Modus deiner Sitzung. Datei-Edits werden also automatisch durchgewunken. Shell-Kommandos, Web-Fetches und MCP-Tools die nicht in deiner Allowlist stehen können dich mitten im Run trotzdem fragen.

Schritt 7, kenn die Limits

Workflows haben harte Grenzen, und die sind gut so. Es gibt keinen Mid-Run-Input, nur Permission-Prompts der Agents können einen Run pausieren. Wenn du zwischen zwei Stufen selbst abnicken willst, bau jede Stufe als eigenen Workflow. Das Skript selbst hat keinen direkten Zugriff aufs Dateisystem oder die Shell, das machen die Agents, das Skript koordiniert sie nur.

Dazu zwei Zahlen die du im Kopf behalten solltest. Bis zu 16 Agents laufen gleichzeitig, auf Maschinen mit wenig CPU-Kernen weniger. Und pro Run sind maximal 1000 Agents erlaubt, das verhindert Endlosschleifen. Wenn dein Workflow gegen diese Wand läuft, war die Aufgabe vermutlich falsch zugeschnitten.

Schritt 8, halt die Kosten klein

Ein Workflow spawnt viele Agents, ein einziger Run kann deutlich mehr Tokens fressen als dieselbe Aufgabe in einer normalen Unterhaltung. Die Runs zählen ganz normal gegen dein Plan-Kontingent und deine Rate-Limits.

Mein Standard-Trick, ich teste erst auf einer kleinen Scheibe. Ein Verzeichnis statt dem ganzen Repo. Eine enge Frage statt einer breiten. In der /workflows-Ansicht siehst du den Token-Verbrauch jedes Agents während der Run läuft, und du kannst jederzeit mit x abbrechen ohne die schon fertige Arbeit zu verlieren. Wenn du sonst für Routine auf ein kleineres Modell wechselst, check /model vor einem großen Run. Du kannst Claude auch sagen, es soll für einfache Stufen ein kleineres Modell nehmen.

Schritt 9, speicher den Workflow als wiederverwendbaren Command

Wenn Claude einen Workflow für eine Aufgabe geschrieben hat die du wiederholst, lohnt sich das Speichern. Ein Review den du auf jedem Branch fährst, läuft danach jedes Mal als dieselbe Orchestrierung.

Tipp /workflows, wähl den Run aus den du behalten willst, und druck s. Im Speicher-Dialog wechselst du mit Tab zwischen zwei Orten. .claude/workflows/ im Projekt teilst du mit allen die das Repo klonen. ~/.claude/workflows/ in deinem Home-Verzeichnis ist in jedem Projekt da, aber nur für dich sichtbar. Enter speichert. Ab dann läuft der Workflow als /<name> in künftigen Sitzungen.

Ein gespeicherter Workflow kann Input über den Parameter args annehmen. Das Skript liest ihn als globale Variable namens args. So fütterst du eine Recherche-Frage, eine Liste von Pfaden oder ein Config-Objekt rein, ohne das Skript jedes Mal anzufassen.

> Run /triage-issues on issues 1024, 1025, and 1030

Claude reicht die Liste als strukturierte Daten durch, das Skript kann also direkt Array- und Objekt-Methoden auf args aufrufen.

Schritt 10, schalt sie wieder aus wenn nötig

Workflows sind nichts für jeden Tag. Wenn dir die automatische Orchestrierung in die Quere kommt, schaltest du sie über den Toggle "Dynamic workflows" in /config aus, das hält über Sitzungen hinweg. Alternativ setzt du "disableWorkflows": true in ~/.claude/settings.json oder die Umgebungsvariable CLAUDE_CODE_DISABLE_WORKFLOWS=1. Fürs ganze Team geht das über die Managed Settings.

Damit hast du den vollen Kreis. Du kennst den eingebauten /deep-research, du lässt Claude eigene Workflows schreiben, du behältst Kosten und Limits im Griff und du speicherst was sich wiederholt. Wenn du als nächstes verstehen willst wie die einzelnen Subagents ticken die ein Workflow orchestriert, geh weiter mit dem Playbook Subagent-Team strukturieren und der Lektion Research, Critic, Analyst. Für den größeren Kosten-Blick passt Claude Code Cost-Controls für den Daily Driver.

Source

Alle Befehle, Versionsnummern und Limits in diesem Playbook stammen aus der offiziellen Claude-Code-Dokumentation, Stand Juni 2026. Hauptquelle ist die Seite Orchestrate subagents at scale with dynamic workflows. Das Opus-4.8-Release und die Versionsangabe v2.1.154 stehen in den Claude Code Release Notes. Da Dynamic Workflows als Research Preview laufen, können sich einzelne Tasten-Belegungen und Defaults noch ändern, im Zweifel die verlinkte Doku checken.