Die Release Notes der Claude-Plattform tragen für den 9. Oktober einen Eintrag, der in der API eine Lücke schließt: Ein Agent in Claude Managed Agents darf jetzt dynamische Workflows nutzen. In der Beta, hinter dem Beta-Header managed-agents-2026-04-01.
Was ein dynamischer Workflow ist
Für Arbeit, die aus vielen Teilen besteht – Anthropics Beispiel sind hunderte Dokumente, die geprüft werden sollen –, schreibt der Agent selbst einen Workflow. Der Workflow ist ein Programm, das viele Agenten in Phasen startet und ihre Ergebnisse zusammenführt. Der Server führt es im Hintergrund als Workflow-Lauf aus.
Der Unterschied zum bisherigen Weg ist die Entscheidung. Bisher hat ein Entwickler die Phasen hingeschrieben und der Agent sie abgearbeitet. Jetzt entscheidet der Agent anhand der Aufgabe, wie viele Agenten in welchen Phasen laufen – und schreibt das Programm dafür.
Wie man es anschaltet
Im multiagent-Feld des Agenten:
{"type": "multiagent_20261001", "workflows": {"type": "enabled"}}Gesteuert wird es über den System-Prompt: Dort steht, wann der Agent einen Lauf starten soll. Verfolgen lässt sich jeder Lauf über workflow_run.*-Ereignisse im Event-Stream der Sitzung.
Dasselbe Werkzeug, jetzt auf der anderen Seite
In Claude Code gibt es dynamische Workflows seit Juni – dort schreibt Claude ein Skript, das Dutzende Agenten dirigiert, und man sieht beim Laufen zu. Was jetzt kommt, ist dieselbe Mechanik serverseitig, für Agenten, die ohne Terminal laufen.
Damit sind Managed Agents in dieser Woche zum zweiten Mal Thema. Am 7. Oktober wurde dort web_fetch eingeschränkt, sodass es nur noch URLs holt, die schon in der Sitzung standen.
Die Reihenfolge der beiden Änderungen ist das Interessante
Erst wird der Netzzugang eines Agenten eingehegt, zwei Tage später darf derselbe Agent beliebig viele weitere Agenten starten. Das passt zusammen, auch wenn es zunächst gegensätzlich aussieht: Was skaliert, muss vorher begrenzt sein.
Für die Praxis heißt das vor allem, dass Kosten und Laufzeit schwerer vorhersehbar werden. Wer einem Agenten erlaubt, sein eigenes Fan-out zu bestimmen, sollte den workflow_run-Stream nicht als Protokoll verstehen, sondern als Messgerät. Und die Anweisung im System-Prompt, wann ein Lauf überhaupt startet, ist dann die eigentliche Obergrenze.