Auf der AI Engineer New York haben CJ Avilla und Harrison Stall von Anthropic am Montag einen Workshop zu Claude Managed Agents gehalten. Im Mittelpunkt stand das Feature, das Anthropic am Freitag angekündigt hat: Dynamic Workflows, von den beiden durchgehend „Flows“ genannt. Über die Ankündigung selbst habe ich am Freitag geschrieben, aus dem Workshop kommt jetzt dazu, wie es wirklich arbeitet.
Claude schreibt das Orchestrierungsprogramm
Bisher musstest du bei Managed Agents einen Koordinator und eine Liste von Subagenten konfigurieren. Bei Flows entscheidet Claude selbst, wie die Arbeit zerlegt wird. Der führende Agent macht einen Plan und schreibt daraus ein Orchestrierungsprogramm: Es startet Agenten, sammelt Ergebnisse ein und steuert, welche Information wohin fließt.
„Flows sind die nächste Fassung der Multi-Agenten-Orchestrierung“, sagt Stall, „bei der du Claude die gesamte Topologie selbst orchestrieren lässt.“ Über mehrere Phasen hinweg erledige das Ganze abgeschlossene, prüfbare Arbeitseinheiten, ohne dass du die Verbindungen dazwischen verwalten musst. Eigene Spezialisten gehen trotzdem: In der Agent-Konfiguration lassen sich vorkonfigurierte Subagenten mitgeben.
Als Einstieg haben die beiden ausgerechnet Unix und Linux bemüht, von Ken Thompsons Urfassung bis zu Torvalds’ Schichten aus Maintainern. Der Punkt dahinter ist weniger pathetisch, als er klingt: Avilla beschreibt das Gefühl, selbst zum Engpass zu werden, wenn man in GitHub sitzt und die Pull Requests von einem Dutzend Agenten abnimmt.
Die Fragerunde war der interessante Teil
Woher weiß Claude, wie viele Agenten eine Aufgabe braucht, und kippt ein einfacher Aktien-Scan plötzlich in Hunderte Subagenten? Stalls Antwort: Evals und niedrige Standardwerte. Für ehrgeizige Aufgaben muss man Parallelisierung ausdrücklich einfordern.
Kennt der führende Agent sein Budget? Nein, sagt Stall, das Modell weiß während des Laufs nicht, wie viel Geld es hat. Setzen kannst du ein Session-Budget. Dem Modell sein Budget zu sagen, mache die Agenten „etwas nervös“ – im Saal gelacht, als Hinweis trotzdem brauchbar.
Wie werden wiederkehrende Flows mit der Zeit günstiger? Avilla verweist auf „Dreaming“, laut Dokumentation eine Research-Preview-Funktion: Sie liest einen bestehenden Memory Store samt alter Sitzungsprotokolle und schreibt daraus einen neu geordneten Store, Duplikate zusammengeführt, veraltete oder widerlegte Einträge ersetzt, neue Einsichten obendrauf.
Zwei weitere Antworten sind für die Praxis wichtig. Einsehbar ist alles: Im Claude Console zeigt eine Graph-Ansicht für jeden Übergang, was der führende Agent an welchen Subagenten übergeben hat. Und untereinander reden können die Subagenten nicht direkt – sie teilen ein Dateisystem und tauschen darüber aus, aber über die API lässt sich kein Subagent anweisen, einem anderen eine Nachricht zu schicken.
Flows sind Rechenzeit, umgerechnet in Fähigkeit
Dass Flows deutlich mehr kosten als ein einzelner Agent, sagt Avilla selbst, am Beispiel desselben Aktien-Scanners. Sie seien dafür deutlich besser darin, alle Details zu finden. Selbst verbessern können sich die Abläufe nicht: Ein geplanter Lauf merkt nicht, dass sein Scan-Modell zu schwach ist, und stellt sich auch nicht um.
Bleibt die Frage, wofür das gedacht ist. Stall sagt es offen: Flows seien ein Weg, Rechenzeit auf harte Probleme zu werfen und mehr Fähigkeit aus den Modellen zu holen. Das Ziel sei, wissenschaftliche Fortschritte für die Allgemeinheit machbar zu machen. Das ist eine große Ansage für ein Feature, dessen Demo ein Aktien-Scanner war. Aber es erklärt, warum das Budget ein eigener Knopf ist und nicht eine Fußnote.