ki-werkzeuge ki-konzepte coding-cli agenten rag

Claude Code Dynamic Workflows: der Agenten-Schwarm in der Research Preview

Redaktion · 2. Juni 2026 · 6 Min. Lesezeit

Anthropic hat am 28. Mai 2026 die Research Preview von „Dynamic Workflows” in Claude Code geöffnet — begleitend zum Release von Opus 4.8. Ein Dynamic Workflow ist kein neues Modell, sondern ein Orchestrierungs-Mechanismus: Claude schreibt zur Laufzeit ein JavaScript-Skript für die beschriebene Aufgabe, und eine separate Runtime führt dieses Skript im Hintergrund aus, während die Session bedienbar bleibt. Statt eine komplexe Aufgabe Zug um Zug in einem einzigen Kontextfenster abzuarbeiten, verteilt das Skript die Arbeit auf viele Subagenten, die parallel laufen und sich gegenseitig prüfen. Die interessante Frage ist nicht, ob das Modell stärker geworden ist — sondern ob die Architektur darüber den Ausschlag gibt.

Was sich konkret geändert hat

Ein Dynamic Workflow ist ein JavaScript-Skript, das Claude zur Laufzeit selbst schreibt. Eine isolierte Runtime führt es im Hintergrund aus; Zwischenergebnisse landen in Skript-Variablen statt im Kontextfenster.
Skaliert auf bis zu 1.000 Subagenten pro Run, maximal 16 gleichzeitig. Die erste Grenze verhindert Endlosschleifen, die zweite begrenzt die lokale CPU-Last.
Getriggert durch das Wort „workflow” im Prompt oder den Befehl /effort ultracode — letzterer plant für jede substanzielle Aufgabe automatisch einen Workflow.
Erfordert Claude Code v2.1.154 oder neuer. Verfügbar in der Research Preview auf allen bezahlten Plänen, inkl. Pro (dort via /config aktivierbar), u. a. Max, Team und Enterprise — plus über die API und die Partner-Plattformen Amazon Bedrock, Google Vertex AI und Microsoft Foundry.
Unabhängige Agenten reviewen sich adversarial: Ein Agent versucht zu widerlegen, was ein anderer gefunden hat, bevor das Ergebnis zurückgemeldet wird.

Was vorher galt

Bis dahin koordinierte Claude Code mehrschrittige Aufgaben über Subagenten, Skills und Agent-Teams — aber in allen drei Fällen blieb Claude selbst der Orchestrator. Das Modell entschied Zug um Zug, welcher Worker als Nächstes startet, und jedes Zwischenergebnis landete im Kontextfenster der laufenden Konversation. Das funktioniert für eine Handvoll delegierter Tasks pro Zug, stößt aber an Grenzen, sobald eine Aufgabe mehr Agenten braucht, als ein Gespräch sauber koordinieren kann: Das Kontextfenster füllt sich mit Zwischenständen, und die Orchestrierung selbst ist nicht wiederholbar — sie steckt im Gesprächsverlauf, nicht in einem Artefakt.

Wer einen Codebase-weiten Bug-Sweep oder eine Migration über hunderte Dateien fahren wollte, musste die Parallelisierung also entweder von Hand zerlegen oder ein eigenes Orchestrierungs-Gerüst bauen.

Was jetzt gilt

Mit der Research Preview verschiebt Anthropic den Plan aus dem Kontextfenster in Code:

1. Der Plan steckt im Skript, nicht im Kontext. Claude schreibt für die beschriebene Aufgabe ein JavaScript-Skript, das die Schleife, die Verzweigungen und die Zwischenergebnisse selbst hält. Die Runtime führt es isoliert von der Konversation aus. Claudes Kontextfenster sieht am Ende nur die fertige Antwort — nicht den Verlauf hunderter Agenten. Das Skript wird unter dem Session-Verzeichnis abgelegt, ist also lesbar, versionierbar und erneut ausführbar.

2. Skalierung mit harten Grenzen. Ein Run darf bis zu 1.000 Subagenten insgesamt starten, aber maximal 16 gleichzeitig (auf Maschinen mit wenigen CPU-Kernen entsprechend weniger). Die Obergrenze von 1.000 ist explizit als Schutz gegen „runaway loops” dokumentiert, die 16er-Parallelität als Schutz der lokalen Ressourcen.

3. Qualität durch Konfrontation, nicht durch mehr Durchläufe. Weil der Plan in Code liegt, kann ein Workflow ein wiederholbares Qualitätsmuster anwenden: unabhängige Agenten prüfen ihre Befunde gegenseitig adversarial, bevor etwas gemeldet wird; ein schwieriger Plan wird aus mehreren Blickwinkeln entworfen und gegeneinander abgewogen. Laut Anthropic ist das der Unterschied zu „einfach mehr Agenten laufen lassen”.

4. Auslöser und Voraussetzungen. Getriggert wird ein Workflow durch das Wort „workflow” im Prompt oder durch /effort ultracode, das xhigh-Reasoning mit automatischer Orchestrierung kombiniert. Voraussetzung ist Claude Code v2.1.154+. Anthropic nennt als Einsatzfälle weit verstreute Bugs, große Migrationen, Security-Audits, Performance-Reviews und Architektur-Analysen.

Einordnung

Das eigentlich Bemerkenswerte an Dynamic Workflows ist nicht die Zahl 1.000. Es ist, dass Anthropic ein Feature, das parallel zum neuen Spitzenmodell Opus 4.8 erscheint, bewusst als Architektur-Werkzeug positioniert — nicht als Modell-Upgrade. Das passt zu einer These, die seit Monaten durch die Fachpresse läuft: KI-Agenten scheitern selten am Modell, sondern an ihrer Architektur. t3n listet als einen der fünf Kern-Fehler ausdrücklich den „Modell-Fokus statt Context-Engineering” — entscheidend sei nicht, welches Modell man wählt, sondern welche Daten der Agent bei jedem Schritt sieht. Ein Agent mit dem schwächeren Modell und exzellentem Context Engineering schlägt demnach einen mit dem stärksten Modell und schlechtem Kontext.

Context Engineering heißt: die Information für jeden Schritt architektonisch planen — präzise Task-Prompts, ein Retrieval-System, das den richtigen Kontext heranzieht, und eine Zwischen-Evaluation nach jedem Schritt. Genau diese Bausteine stecken in Dynamic Workflows: das Aufteilen in scharf umrissene Teilaufgaben, das parallele Heranziehen von Quellen (der gebündelte /deep-research-Workflow zieht und cross-checkt Quellen gegeneinander) und das adversariale Prüfen vor der Rückmeldung. Wer verstehen will, warum das mehr ist als „mehr Rechenzeit”, landet schnell bei den Grundlagen von Context Engineering und bei Agentic RAG — also Retrieval, das nicht ein einziges Mal stur läuft, sondern vom Agenten gesteuert iteriert. In der Praxis hängt die Qualität solcher Pipelines oft an Details wie Reranking und Contextual Retrieval, die entscheiden, ob die richtigen Belege überhaupt vor dem Agenten landen.

Die nüchterne Lesart: Anthropic verlagert mit Dynamic Workflows den Hebel von „besseres Modell” auf „bessere Orchestrierung”. Das deckt sich mit der Abgrenzung von Modell und Agent, wie sie auch it-daily zieht: Modelle erkennen Muster, Agenten orchestrieren Workflows und greifen dabei auf Modelle zu. Wer das ernst nimmt, baut weniger am Prompt herum und mehr am System — an Aufteilung, Retrieval und Prüf-Schleifen. Wir bei boostN arbeiten genau an solchen Architektur- und Workflow-Mustern; insofern bestätigt das Release eine Richtung, die wir für tragfähiger halten als das reine Warten auf das nächste Modell. Offen bleibt, ob die adversariale Selbstprüfung in der Praxis wirklich verlässlicher wird oder nur teurer — die Token-Kosten eines Runs mit hunderten Agenten sind erheblich, und Anthropic verlangt vor dem ersten Lauf bewusst eine Bestätigung.

Was du jetzt tun kannst

Wenn du Dynamic Workflows testen willst: Aktualisiere Claude Code auf v2.1.154+ und starte mit dem gebündelten /deep-research-Workflow oder dem Wort „workflow” im Prompt auf einem kleinen Ausschnitt — etwa einem einzelnen Verzeichnis statt dem ganzen Repo. Die /workflows-Ansicht zeigt den Token-Verbrauch pro Agent live; brich den Run dort jederzeit ab, ohne fertige Arbeit zu verlieren.

Wenn dich die Kosten abschrecken: Behandle einen Workflow wie eine Investition, nicht wie eine Standard-Anfrage. Ein Run mit vielen Agenten verbraucht deutlich mehr Tokens als die gleiche Aufgabe im Gespräch und zählt auf dein Plan-Limit. Teste auf einem schmalen Slice, bevor du eine große Migration startest.

Wenn dich die Architektur-These interessiert: Sieh dir an, wie ein Agenten-System sinnvoll aufgebaut wird — die Bausteine (Task-Zerlegung, Retrieval, Evaluation) erklären wir ausführlich im Lexikon-Artikel zum Bauen von KI-Agenten.

Grundlagen dazu im Lexikon

Wie Retrieval-Augmented Generation funktioniert und warum sie der Kern guter Agenten-Architektur ist, steht hier: → RAG verstehen — Retrieval-Augmented Generation

Entdecke mehr

Lexikon

Themenuebersicht

KI-Werkzeuge Coding-CLI KI-Konzepte Agenten RAG