Claude Managed Agents Dynamic Workflows: Der Agent schreibt den Fan-out, das Budget muss vorher stehen

Seit dem 9. Oktober kann ein Agent in Claude Managed Agents einen Workflow schreiben: ein Programm, das viele Agenten in Phasen laufen lässt und ihre Ergebnisse zusammenführt. Der Server führt es im Hintergrund als Workflow-Run aus. Das Feature ist in der Beta unter dem Header managed-agents-2026-04-01 und kommt mit einem neuen multiagent-Typ, multiagent_20261001.

Ich habe das nicht mit meinem eigenen Key ausgeführt. Alles Folgende stammt aus der Dokumentation, Stand 13. Oktober 2026, und wo ich eine eigene Lesart gebe, sage ich es dazu. Die Einrichtung ist kurz. Schwieriger ist, dass die entscheidenden Einstellungen vor der ersten Nachricht gewählt sein müssen, dass sich die Kostengrenze nachträglich nicht mehr setzen lässt und dass danach das Modell den Plan für die Arbeit schreibt, an einer Stelle, die du nicht siehst.

Was macht ein Dynamic Workflow in Claude Managed Agents?

Er verlagert die Orchestrierung aus der Konversation in Code, den das Modell geschrieben hat. Bei Subagenten delegiert der Agent eine Aufgabe, liest den Bericht und entscheidet den nächsten Schritt selbst. Bei einem Workflow übernimmt das ein Programm: Es startet Agenten, sammelt jedes Ergebnis ein, reicht Ergebnisse an andere Agenten weiter, wiederholt einen Schritt und entscheidet, was passiert, wenn einer scheitert. Die Ergebnisse gehen an das Programm, nicht an den Agenten, den die Session ausführt. Der bleibt frei, mit dir zu sprechen oder seinen Turn zu beenden.

Jeder Agent in einem Run arbeitet in einem eigenen Session-Thread mit eigenem Gesprächsverlauf, in der gemeinsamen Sandbox der Session. Jeder Thread sieht also dieselben Dateien. Die Doku empfiehlt Workflows für die meiste Arbeit, die mehr als einen Agenten braucht, und nennt Audits, Migrationen, Deep Research und Gegenprüfungen als Beispiele.

Wie schaltest du Dynamic Workflows in Claude Managed Agents ein, und wie bleiben sie abgeschaltet?

Du setzt den multiagent-Block des Agenten auf den neuen Typ. Die Release Note zeigt die explizite Form:

{
  "multiagent": {
    "type": "multiagent_20261001",
    "workflows": { "type": "enabled" }
  }
}

Die Zeile workflows ist allerdings nicht das, was das Feature einschaltet. Mit diesem Typ sind workflows und subagents beide standardmäßig aktiviert, und bei beiden ist inline_agents aktiviert. Damit kann der Agent oder ein Workflow Agenten an Ort und Stelle definieren. Ein Block, der nur den Typ enthält, gibt dir alles davon.

Am meisten zählt das bei einer Migration. Wenn du einen Agenten vom älteren coordinator-Typ umstellst, ersetzt du den ganzen multiagent-Block, und was du weglässt, bekommt seinen Standardwert. Ein Agent, der bisher nur an zwei von dir aufgelistete Subagenten delegieren konnte, kann nach dem Update Workflow-Runs starten und eigene Subagenten definieren. Um eines von beiden abgeschaltet zu lassen, sendest du im selben Update {"type": "disabled"} dafür. null bewirkt das Gegenteil von dem, wonach es aussieht: Es stellt den Standard wieder her, und der Standard ist aktiviert.

Im selben Abschnitt stecken zwei kleinere Fallen. Eine Session kopiert die Einstellung beim Anlegen, eine Änderung am Agenten ändert also keine Session, die schon existiert. Und das Tool-Namenspräfix ant__ ist jetzt reserviert: Ein Agent mit einem so benannten Custom Tool scheitert bei jedem Update mit einem 400, bis das Tool umbenannt ist.

Wer entscheidet, wann ein Workflow-Run in Claude Managed Agents startet?

Der Agent, und sonst wird niemand gefragt. Es gibt keinen API-Aufruf, der einen Run startet. Du beschreibst die Arbeit in einer user.message, und der Agent bestimmt, ob und wann er einen startet. Die Doku sagt es in einem Satz:

Permission policies apply to the tools that a run's agents call, not to
starting the run.

Dein Hebel ist Prosa. Die Beispielanweisungen der Doku sagen einem Agenten für Vertragsprüfung, bei mehr als ein paar Verträgen einen Run zu starten und ein oder zwei selbst zu erledigen. Du kannst auch hineinschreiben, wie die Arbeit aufzuteilen ist, was passiert, wenn ein Agent scheitert, und ein Zeitlimit.

Meine Lesart: Das ist die schwächste Kontrolle im Feature, und genau auf die stützt sich die Doku. Eine Anweisung in den Systemanweisungen des Agenten wird abgewogen, nicht durchgesetzt. Das ist der Punkt von Ein Prompt ist keine Invariante. Hier liegt der Fall vor, der diesem Essay die meisten Sorgen macht: eine Regel, deren Verletzung Geld kostet, und in der API kein Platz für ein Gate. Den Tool-Aufruf, der einen Run startet, siehst du auch nicht. Das erste Zeichen ist ein workflow_run.created-Event im Stream. Das Modell entscheidet also über den Fan-out, und du erfährst es danach. Begrenzt wird er durch das, was du vor der ersten Nachricht gesetzt hast.

Wie deckelst du, was ein Workflow-Run in Claude Managed Agents ausgeben kann?

Mit einem Session-Budget, und nur beim Anlegen der Session. Ein Run hat keinen eigenen Preis. Die Tokens seiner Agenten werden zu den Tarifen des jeweiligen Modells abgerechnet, wie der Rest der Session. Das Budget ist die einzige Kostengrenze, und darunter gibt es keine Grenzen pro Thread:

{
  "agent": "$AGENT_ID",
  "environment_id": "$ENVIRONMENT_ID",
  "budget": {
    "type": "limit",
    "max_list_cost": { "amount": "2000", "currency": "USD" }
  }
}

Der Betrag ist eine ganze Zahl in US-Cent, als String geschrieben, "2000" sind also 20 $. Vier Details entscheiden, ob die Grenze tut, was du erwartest. Sie lässt sich später nicht hinzufügen: Ein Budget an eine Session zu hängen, die ohne eines angelegt wurde, gibt einen 400 zurück, und auch das Entfernen lässt sich nicht rückgängig machen. Gemessen wird zum Listenpreis, nicht zu deinem Vertragspreis, und Laufzeit der Session und Websuchen zählen mit. Sie ist kein exakter Stopp. Jeder Thread beendet die Modellanfrage, die er schon begonnen hat, und in einem Run können 64 Threads gleichzeitig arbeiten (eine Zahl, die die API nicht garantiert). Die Überschreitung beträgt also bis zu eine Anfrage pro arbeitendem Thread. Und an der Grenze geht die Session mit budget_reached in den Leerlauf (oder mit requires_action, wenn ein Tool-Aufruf noch auf deinen Client wartet) und lehnt eine user.message ab, bis du das Budget erhöhst oder entfernst. Die Lebensdauer eines pausierten Runs läuft dabei weiter, der Run kann also mit timeout_error enden, während er wartet.

Die übrigen Limits sind Stückzahlen: 1.000 gestartete Agenten über die Lebensdauer eines Runs, eine Lebensdauer von 24 Stunden, sofern der Agent keine kürzere setzt, und standardmäßig 10 gleichzeitig offene Runs in einer Session. Keines davon ist in Geld bemessen.

Das Modell ist die andere Kosteneinstellung. Ein Inline-Agent nutzt das Modell des Agenten, den die Session ausführt. Ein Agent auf dem größten Modell fächert also auf dem größten Modell auf. Der dokumentierte Weg, für einen Teil eines Runs ein günstigeres zu nehmen: Du legst diese Agenten selbst an und listest sie in workflows.predefined_agents. Das Workflow-Tool von Claude Code selbst bekam am selben Tag eine Umgebungsvariable dafür, CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL in v2.1.296. In Managed Agents führt der Weg über die Agentenliste.

Wie verfolgst du einen Workflow-Run in Claude Managed Agents und erkennst, dass er fertig ist?

Du liest workflow_run.*-Events im Event-Stream der Session: created (mit dem Namen des Runs und den deklarierten Phasen), status_running, status_idle, phase_started, phase_ended, status_ended und error. Die Arbeit ist erledigt, wenn zwei Dinge zutreffen: Jeder Run, dessen Erstellung du gesehen hast, hat sein workflow_run.status_ended, und danach kommt ein session.status_idle mit end_turn, das nicht durch deine eigene Anfrage ausgelöst wurde. Nach einem Interrupt zählt nur ein Idle, das auf deine nächste user.message folgt. Ein Idle allein beweist nichts, weil ein pausierter Run die Session in den Leerlauf gehen lässt, während der Run noch offen ist, und weil der Agent einen weiteren Run starten kann, wenn er ein Ergebnis liest.

Run-Events lösen keine Webhooks aus. Eine neue Verbindung spielt nicht nach, was du verpasst hast, und kein Endpoint listet Runs auf. Nach einem Reconnect baust du den Zustand also neu auf, indem du die Events der Session auflistest. Außerdem kann ein Thread eines Runs auf eine Tool-Bestätigung von deinem Client warten, während die Session auf running bleibt. Antworte also, wenn das Event eintrifft. Eine Bestätigung, die zu spät kommt, gibt 200 zurück, und das heißt laut Doku nicht, dass das Tool gelaufen ist („doesn’t mean that the tool ran“).

Um einen Run zu stoppen, bittest du darum. Kein Event, das du sendest, beendet einen. user.interrupt stoppt den Turn des Agenten und beendet keinen Run. Du sendest eine user.message, in der du den Agenten bittest, seine Runs zu stoppen. Das Archivieren der Session beendet die Runs ebenfalls, aber ein Archivieren kann einen 400 zurückgeben, solange ein Run offen ist. Die dokumentierte Reihenfolge ist daher: um den Stopp bitten, auf das status_ended jedes Runs warten, dann archivieren.

Heißt „completed“, dass ein Workflow-Run in Claude Managed Agents erfolgreich war?

Nein, und die Doku sagt das ausdrücklich:

The workflow finished running. The result doesn't say whether the work
passed. A run can end completed even though work on its threads failed, or a
thread couldn't be created.

Um gescheiterte Arbeit zu finden, liest du die Events jedes einzelnen Threads des Runs. Das Fehlerergebnis ist nicht genauer: program_error nennt seine Ursache nicht. Du siehst auch weder den Code des Workflows noch die Tool-Aufrufe, die den Run steuern, noch das Ergebnis, das jeder Thread an das Programm zurückgegeben hat. Die Doku schlägt vor, den Agenten nach dem Run zu bitten, den Workflow Wort für Wort auszugeben. Das ist die Darstellung des Modells davon, was es ausgeführt hat. Sie ist lesenswert, und sie ist kein Log.

Ein weiterer Satz auf der Seite zu Workflow-Runs verdient einen Platz in deinem Design: „A run can create more than one thread for the same piece of work, so make the tools your agents call safe to call twice.“ Ein Run kann also für dasselbe Stück Arbeit mehr als einen Thread anlegen, und die Tools deiner Agenten sollen einen zweiten Aufruf vertragen. Wie oft das passiert, dazu verspricht die Doku nichts. Ich lese es als das At-least-once-Problem, das ich in Dein Multi-Agenten-System ist ein verteiltes System beschrieben habe: Arbeit, die neu ausgegeben werden kann, muss gefahrlos zweimal laufen können. Das Etikett stammt von mir. Die Anweisung, Tools einen zweiten Aufruf vertragen zu lassen, stammt vom Anbieter.

Meine Regel dort war, dass das Erfolgssignal vom Artefakt kommt, geprüft von etwas, das der arbeitende Agent nicht kontrolliert. Sie gilt weiter, und die gemeinsame Sandbox ist der Ort, sie anzuwenden. Mein Vorschlag, ungetestet: Sag dem Workflow in den Systemanweisungen, pro Arbeitseinheit eine Ergebnisdatei zu schreiben, und zähle und prüfe die Dateien dann selbst, von außerhalb des Runs. Eine Abschlusszusammenfassung wie im Beispiel der Doku, „41 of the 300 contracts have one,“ ist eine Behauptung über Threads, die du nicht gelesen hast.

Was solltest du setzen, bevor du Workflows in Claude Managed Agents für unbeaufsichtigte Arbeit aktivierst?

Drei Einstellungen, dann drei Gewohnheiten. Setz das Budget, wenn du die Session anlegst, und bemiss es mit Blick auf die Überschreitung pro Thread, denn nachträglich lässt es sich nicht mehr setzen. Deaktiviere inline_agents unter workflows und liste die Agenten auf, die ein Run nutzen darf: Ein Inline-Agent bekommt derzeit alle Tools, MCP-Server und Skills des Session-Agenten (die API garantiert nur eine Teilmenge), und laut Doku kannst du ihn nicht so einschränken wie einen Agenten, den du selbst definierst. Deaktiviere subagents ausdrücklich, wenn du nur Workflows willst, denn Weglassen aktiviert es. Die Session kopiert die multiagent-Einstellungen des Agenten beim Anlegen.

Die Gewohnheiten sind keine Felder. Mach jedes Tool, das ein Agent eines Runs aufrufen kann, sicher für einen zweiten Aufruf. Schreib in die Systemanweisungen, wann ein Run zu starten ist und wann nicht, und behandle das als Orientierung. Prüf das zusammengeführte Ergebnis von außerhalb des Runs, bevor du ihm traust.

Ein Block, der die zweite und dritte Einstellung umsetzt, zusammengesetzt aus den dokumentierten Feldern:

{
  "multiagent": {
    "type": "multiagent_20261001",
    "subagents": { "type": "disabled" },
    "workflows": {
      "type": "enabled",
      "inline_agents": { "type": "disabled" },
      "predefined_agents": [
        { "type": "agent", "id": "agent_01Lm4cV8yQ2tNs7XbKdR5h", "version": 2 }
      ]
    }
  }
}

Die Tools, die diese Agenten aufrufen, behalten ihre Permission Policies auch innerhalb eines Runs. Die Standardwerte, die ich bei der web_fetch-Änderung durchgegangen bin, gelten also für jeden Thread, den ein Workflow anlegt, bis zu 64 davon gleichzeitig.

Wo ich der Doku nicht folge, ist das Wort „meiste“. Ein Workflow ist die richtige Form, wenn die Aufteilung nicht im Voraus bekannt ist und die Teile unabhängig sind. Kennst du die Aufteilung schon, hält ein selbst geschriebenes Skript den Plan an einer Stelle, an der du ihn lesen kannst, bevor er läuft, und eine Liste von Subagenten legt zumindest fest, wer aufgerufen werden kann, auch wenn der Agent weiterhin jeden Schritt entscheidet. Hier wird der Plan zur Laufzeit geschrieben, vom Modell, und dir nur gezeigt, wenn du danach fragst.