Comment les dynamic workflows d'Anthropic coordonnent les agents Claude

Lors de l'atelier AI Engineer New York 2026, les ingénieurs d'Anthropic CJ Avilla et Harrison Stall ont présenté les dynamic workflows, surnommés « flows », une nouvelle forme d'orchestration multiagent destinée à Claude Managed Agents. Annoncée la veille, la fonctionnalité vise, selon l'entreprise, les charges de travail les plus ambitieuses. Pour l'expliquer, les deux présentateurs se sont appuyés sur l'histoire des systèmes d'exploitation : de la création d'Unix par Ken Thompson à l'évolution de Linux, passé d'un seul mainteneur, Linus Torvalds, à des couches de mainteneurs de confiance. L'idée centrale est que des agents travaillant sur de grands projets ont besoin d'un niveau d'organisation comparable.

Le constat de départ est opérationnel. Avilla a décrit le sentiment de nombreux développeurs qui orchestrent aujourd'hui beaucoup d'agents : ils deviennent eux-mêmes le goulot d'étranglement, face à une multitude de pull requests à relire et valider manuellement dans GitHub.

Les dynamic workflows sont nés dans Claude Code, sous le concept de « harness pour chaque tâche ». Ils vont toutefois au-delà d'un agent unique ou d'une équipe prédéfinie. Le principe est que Claude choisit lui-même l'organisation des agents. Jusqu'ici, Claude Managed Agents exigeait qu'un développeur configure un coordinateur et une liste de sous-agents. Avec les flows, l'agent principal établit un plan, puis Claude rédige un programme d'orchestration qui lance les agents, collecte leurs résultats et gère les flux d'information. Stall présente cette évolution comme la prochaine version de l'orchestration multiagent, où Claude gère l'ensemble de sa propre topologie. Il reste possible de fournir des sous-agents spécialisés préconfigurés dans la configuration de l'agent. L'ensemble est accessible depuis la Claude Console, l'interface utilisée par les développeurs qui accèdent à Claude via l'API.

Pour illustrer la démonstration, les présentateurs ont montré un exemple plus modeste : un scanner de liste de surveillance boursière. Il reproduit le schéma de base du dispositif : une phase de scan répartit les tickers entre des agents aux contextes isolés, puis une phase de revue examine les résultats avant de produire un rapport.

Les questions de la salle ont mis en lumière plusieurs points de vigilance. Le premier concerne le nombre d'agents : un simple scan de tickers peut-il déclencher des centaines de sous-agents ? Stall répond que la réponse passe par les évaluations (evals) et des valeurs par défaut plus basses, les tâches ambitieuses nécessitant généralement d'encourager explicitement une plus grande parallélisation. Le second point touche au budget de tokens. Le modèle ne connaît pas son budget pendant l'exécution, mais le développeur peut fixer un budget de session. Stall a par ailleurs remarqué qu'informer les modèles de leur budget pourrait les rendre « un peu anxieux ».

Pour rendre les flows répétés moins coûteux au fil du temps, Avilla a évoqué la fonctionnalité « dreaming », présentée dans la documentation comme une fonctionnalité en aperçu de recherche. Un dream lit un magasin de mémoire existant avec les transcriptions de sessions passées, puis produit un magasin réorganisé, où les doublons sont fusionnés et les entrées obsolètes ou contredites remplacées. Interrogé sur la capacité d'un flow à s'améliorer lui-même, par exemple en remettant en cause son modèle de scan, Stall a répondu que ce n'était pas intégré, mais que le hill-climbing et le dreaming pourraient servir à améliorer la boucle.

Sur la visibilité, les développeurs peuvent inspecter les échanges via la fonctionnalité de graphe de la Claude Console, notamment la charge utile transmise par l'agent principal à chaque sous-agent. Concernant la communication entre sous-agents, Stall indique qu'ils partagent un système de fichiers pour échanger des informations, mais qu'un développeur ne peut pas directement demander à un sous-agent d'envoyer un message à un autre via l'API.

Sur le coût, Avilla reconnaît que les flows coûtent « beaucoup plus cher » qu'une approche à agent unique, mais affirme qu'ils sont aussi « beaucoup plus efficaces pour trouver tous les détails ». La question de l'ambition scientifique a aussi été posée, en référence à une démonstration récemment annoncée par OpenAI sur le problème du prix du millénaire de Navier–Stokes. Stall n'a pas détaillé la façon dont Anthropic aborde ces problèmes, mais a indiqué que l'objectif est de permettre au grand public de s'y attaquer. Les flows, selon lui, constituent un moyen de consacrer du test-time compute aux problèmes difficiles.