Dynamic Workflows in Claude Code: Wenn die KI ihre eigene Orchestrierung schreibt

Die meisten von uns bauen ihre Agenten-Workflows noch von Hand: Prompt absetzen, Output kopieren, in den nächsten Prompt einsetzen, korrigieren, wiederholen. Mit Dynamic Workflows dreht Anthropic dieses Muster um — Claude schreibt die Orchestrierung selbst. Eine Einordnung, was sich technisch ändert und wann sich der Aufwand lohnt.

Der eigentliche Wendepunkt steckt in einem Beispiel

Jarred Sumner hat den JavaScript-Runtime Bun von Zig nach Rust portiert. Rund 750.000 Zeilen Rust, 99,8 Prozent der bestehenden Testsuite grün, elf Tage vom ersten Commit bis zum Merge. Nicht von Hand und nicht in einer langen Pair-Programming-Session mit Claude, sondern mit Dynamic Workflows — dem Orchestrierungs-Feature, das Anthropic am 28. Mai 2026 zusammen mit Claude Opus 4.8 als Research Preview veröffentlicht hat.

Eine Migration dieser Grössenordnung in elf Tagen ist kein PR-Gimmick. Sie zeigt eine architektonische Verschiebung, die für jeden relevant ist, der ernsthaft mit KI-Agenten arbeitet: Der Plan wandert aus dem Gespräch in den Code.

Was ein Dynamic Workflow eigentlich ist

Die Standard-Harness von Claude Code lässt Claude im selben Context Window planen und ausführen. Für den Grossteil der Coding-Arbeit funktioniert das hervorragend. Es gibt aber eine Klasse von Aufgaben, an der ein einzelnes Context Window zerbricht: lang laufend, massiv parallel, hochgradig strukturiert — oder Arbeit, deren Ergebnis aktiv gegengeprüft werden muss.

Bisher hat Anthropic für solche Fälle eigene Harnesses gebaut — etwa für Research oder Code Review. Ein Dynamic Workflow automatisiert genau diesen Schritt: Claude schreibt sich die Harness on the fly selbst, als JavaScript-Skript, massgeschneidert für die konkrete Aufgabe. Dieses Skript entscheidet, welche Subagenten in welcher Reihenfolge starten, mit welcher Schleifen- oder Verzweigungslogik — und hält den Zwischenstand in Variablen, die ausserhalb des Gesprächs leben.

Daraus ergeben sich drei Dinge, die die Standard-Harness nicht leisten kann:

• Isolation pro Agent. Jeder Subagent bekommt sein eigenes Context Window mit einem einzigen, fokussierten Ziel. Keine Kreuzkontamination zwischen Teilaufgaben.
• Modellwahl pro Agent. Der Workflow entscheidet, welches Modell welcher Subagent nutzt: Opus für harte Reasoning-Schritte, Haiku für günstige Exploration, Sonnet für die Mitte.
• Persistenz. Der Fortschritt wird laufend gespeichert. Wird ein Lauf unterbrochen, setzt er beim Wiederaufnehmen dort an, wo er aufgehört hat, statt neu zu starten.

Einen Workflow startet man auf drei Arten. Am einfachsten in eigenen Worten — «erstell mir einen Workflow, der …» oder «nutz dafür einen Workflow»: Claude behandelt eine direkte Bitte als Opt-in. Wer einen expliziten Auslöser will, schreibt das Schlüsselwort ultracode in den Prompt; das führt eine einzelne Aufgabe als Workflow aus, ohne den Effort-Level der Session zu ändern. Und über /effort ultracode schaltet man die Session-weite Auto-Orchestrierung ein: Claude hebt den Reasoning-Aufwand auf das Maximum und entscheidet selbst, wann eine Aufgabe gross genug für einen Workflow ist.

Eine kleine, aber wichtige Änderung seit dem Launch: Ursprünglich genügte das blosse Wort «workflow» im Prompt als Auslöser. Nach Nutzer-Feedback hat Anthropic den expliziten Auslöser auf ultracode umgestellt — so startet Claude keinen Dynamic Workflow mehr, wenn man «workflow» nur beiläufig erwähnt. Formulierungen wie «nutz dafür einen Workflow» funktionieren weiterhin.

Die drei Fehlermodi, die Workflows strukturell lösen

Um zu verstehen, wann sich ein Workflow lohnt, muss man verstehen, was er repariert. Je länger ein Agent in einem einzigen Context Window an einer komplexen Aufgabe arbeitet, desto anfälliger wird er für drei Muster:

1. Vorzeitiges Aufhören. Der Agent erklärt eine mehrteilige Aufgabe nach Teilfortschritt für erledigt — bearbeitet 20 von 50 Punkten eines Security-Reviews und verbucht den Rest als «behandelt».
2. Selbstbevorzugung. Wird Claude gebeten, das eigene Ergebnis gegen ein Rubric zu prüfen, bevorzugt es tendenziell seine eigene Arbeit. Ein Prüfer mit eigenem Interesse ist kein fairer Prüfer.
3. Zieldrift. Über viele Turns — besonders nach jeder Komprimierung des Kontexts — geht die Treue zum ursprünglichen Ziel schleichend verloren. «Mach X nicht»-Vorgaben verschwinden irgendwann unbemerkt.

Ein Workflow adressiert alle drei auf struktureller Ebene: getrennte Claude-Instanzen mit eigenem Kontext, fokussiertem Ziel und isoliertem State. Wenn die eigene Aufgabe an einem dieser Muster leidet, ist das das Signal, zum Workflow zu greifen.

Die Kern-Primitive: agent, parallel, pipeline

Man muss kein Compiler-Bauer sein, um Workflows zu lesen. Drei Funktionen erledigen den Grossteil der Arbeit:

• agent() startet einen einzelnen Subagenten mit einem Ziel, einem Modell und optional einem Ausgabe-Schema.
• parallel() ist eine Barriere: fächert die Arbeit auf und wartet, bis alles fertig ist, bevor es zurückgibt.
• pipeline() ist streaming: Jedes Element fliesst unabhängig durch alle Stufen.

Die entscheidende Frage bei der Wahl: Brauche ich alle Ergebnisse, bevor ich weitermachen kann? Ja → parallel(). Nein → pipeline() (günstiger und insgesamt schneller). Diese beiden zu verwechseln ist einer der häufigsten Fehler — die Barriere ist kein Detail, sondern der ganze Unterschied.

Rund um diese Primitive kristallisieren sich in der Praxis ein paar Muster heraus, die selten allein auftreten — ein realer Workflow kombiniert meist zwei bis vier davon:

• Fan-out und Synthese. Eine klar aufzählbare Liste von Arbeitsschritten (50 Dateien, 200 Endpunkte) parallel abarbeiten, dann ein Agent, der alles zu einer priorisierten Antwort zusammenführt. Das Standardrezept gegen Zieldrift.
• Unabhängige Gegenprüfung. Zu jedem produzierenden Agenten ein separater Agent, der das Ergebnis gegen ein Rubric prüft — ohne zu wissen, wer es erzeugt hat. Der strukturelle Fix gegen Selbstbevorzugung. Autor und Prüfer dürfen nie dieselbe Instanz sein.
• Generieren und filtern. Viele Ideen erzeugen, dann gnadenlos nach Qualität filtern. Das Gegenteil davon, Claude um «die beste Antwort» zu bitten — der Agent committet spät, nachdem jede Option herausgefordert wurde.
• Turnier. Statt 1.000 Elemente in einem Prompt zu sortieren (Qualität bricht ein, Kontext reisst), vergleichen frische Agenten jeweils nur zwei Elemente. Vergleichendes Urteil ist verlässlicher als absolute Bewertung — vor allem bei geschmacksabhängiger Arbeit.
• Schleife bis fertig. Bei unbekanntem Arbeitsumfang Agenten spawnen, bis eine Stoppbedingung erfüllt ist (keine neuen Findings, kein Fehler mehr im Log), statt eine feste Anzahl Durchläufe zu fahren.

Der pragmatische Weg, sich das einzuprägen: Erst den Fehlermodus der eigenen Aufgabe identifizieren, dann das Muster wählen, das ihn verhindert. Drift → Fan-out. Selbstbevorzugung → unabhängige Gegenprüfung. Offenes Ende → Schleife bis fertig. Schwer bewertbar → Turnier.

Wann sich ein Workflow lohnt — und wann nicht

Hier liegt der wichtigste Satz, und er kommt von Anthropic selbst: Dynamic Workflows verbrauchen deutlich mehr Token als eine typische Claude-Code-Session. Das ist kein Werkzeug für jeden Task.

Die häufigste Fehlentscheidung ist, einen Workflow zu starten, wo eine normale Session genügt hätte. Die ehrliche Faustregel: Würde eine reguläre Claude-Code-Session die Aufgabe in fünf Minuten erledigen, braucht es keinen Workflow und kein Gremium aus fünf Reviewern.

Drei Kontrollmechanismen machen aus «cool, aber teuer» ein Werkzeug, das man unbeaufsichtigt laufen lassen kann:

• /goal setzt eine harte Abschlussbedingung. In Kombination mit dem Schleifen-Muster: «hör nicht auf, bis eine Theorie hält». Ohne /goal stoppt ein Workflow am ersten weichen Abschlusspunkt.
• /loop lässt den gesamten Workflow auf einem wiederkehrenden Zeitplan laufen — sinnvoll für kontinuierliche Triage oder wöchentliche Research-Updates.
• Explizites Token-Budget. Ein simples «nutze 10k Token» im Prompt deckelt den Lauf. Ohne Cap kann ein ehrgeiziger Workflow auf das Fünf- bis Zehnfache des Erwarteten anwachsen.

Beim ersten Trigger zeigt Claude Code ohnehin an, was laufen wird, und fragt nach Bestätigung. Org-Admins können Workflows über Managed Settings auch ganz abschalten.

Ein Sicherheitsmuster, das nicht optional ist

Sobald ein Workflow nicht von einem selbst verfasste Inhalte liest — Support-Tickets, Bug-Reports, Nutzerfeedback, gescrapte Webseiten, Output fremder APIs — muss man annehmen, dass dieser Inhalt Prompt-Injection enthalten kann.

Die Lösung heisst Quarantäne: Die Agenten, die den nicht vertrauenswürdigen Inhalt lesen, dürfen keine privilegierten Aktionen ausführen. Separate Agenten, die den Rohinhalt nie zu sehen bekommen, übernehmen das Handeln. Ein 30-Zeilen-Reader-Agent im Read-only-Modus kostet fast nichts und entfernt eine ganze Klasse von Angriffsvektoren. Wer Inhalte verarbeitet, die nicht von ihm oder einem vertrauenswürdigen Team stammen, sollte das nicht als Kür behandeln.

Funktioniert ein Workflow, gehört er gespeichert

Ein bewährter Workflow lässt sich sichern und wird so wiederverwendbar — lokal über mehrere Projekte hinweg oder verpackt als Skill, den auch andere installieren und identisch ausführen können.

Eine praktische Nuance dabei: Beim Verpacken in einen Skill sollte man Claude anweisen, den Workflow als Template zu behandeln, nicht als Skript zum wortwörtlichen Ausführen. Das lässt Raum, die Form an die konkrete Aufgabe anzupassen, ohne die Gesamtstruktur zu verlieren — besonders wertvoll bei flexiblen Mustern wie «Deep Verification» oder «Triage».

Einordnung

Dynamic Workflows sind kein neues Modell und kein Plugin, sondern eine subtile, aber tiefe architektonische Verschiebung: Der Orchestrierungsplan verlässt das Context Window und wird ausführbarer Code. Damit löst Anthropic ein Problem, das jeder kennt, der schon einmal versucht hat, einen Agenten über Stunden bei der Stange zu halten — die Tatsache, dass Verlässlichkeit über lange Horizonte nicht aus mehr Prompt-Kunst entsteht, sondern aus Struktur.

Für Teams in der DACH-Region, die KI-gestützte Entwicklung ernst nehmen, ist die relevante Frage nicht «soll ich das ausprobieren?», sondern «welche meiner Aufgaben sind tatsächlich lang laufend, parallel oder kritisch genug, dass sich der Token-Aufwand rechnet?». Wer diese Frage ehrlich beantwortet, hat die halbe Lernkurve schon hinter sich.

Dynamic Workflows sind seit dem 28. Mai 2026 als Research Preview in der Claude Code CLI, im Desktop-Client und in der VS-Code-Erweiterung verfügbar (Max-, Team- und Enterprise-Pläne sowie über die Claude API, Amazon Bedrock, Vertex AI und Microsoft Foundry). Quelle: Introducing dynamic workflows in Claude Code · Dokumentation.