OpenAI a open-sourcé Symphony le 17 mai — un SPEC.md plus une implémentation de référence Elixir pour orchestrer des agents code autonomes depuis un task board de gestion de projet. Symphony watch en continu le board (issues, tâches, tickets, milestones), assigne chaque tâche active à un agent dédié qui roule autonomement jusqu'à ce que la tâche soit faite, et surface le résultat pour qu'un humain l'accepte ou la rejette. github.com/openai/symphony. Le framing d'OpenAI : « le coût d'un agent qui fait des erreurs est significativement réduit, puisque ça implique principalement de reviewer du travail complété et de le rejeter » — review async batched plutôt que correction interactive in-flight.
Le choix architectural qui sépare Symphony des frameworks d'agents existants, c'est le control plane. LangGraph modélise l'état comme un graph que l'orchestrateur possède ; AutoGen traite ça comme une conversation inter-agents ; CrewAI utilise une assignation explicite de role/tâche. Symphony parasite n'importe quel issue tracker que l'équipe utilise déjà comme control plane — chaque tâche qui existe dans le board de l'équipe est un input d'agent, et l'output de l'agent flow back comme updates de ticket. C'est un design point non-trivial : ça élimine l'UI d'orchestrateur bespoke et réutilise le workflow de review humaine que les équipes opèrent déjà. Ça contraint aussi la surface de tâche de l'agent à « ce qui fit dans une issue », ce qui est un prior utile. Détail d'implémentation notable : Elixir, pas Python ou TypeScript. La sémantique de supervision-tree OTP d'Elixir map clean sur des processes per-agent long-running qui ont besoin de restart et d'isolation.
Positionne ça contre le reste de la semaine d'orchestrateurs en mai. Anthropic a shippé Routines (workflows Claude Code sur le cloud d'Anthropic, déclenché par event de repo, pricing pas publié). BerriAI a open-sourcé LiteLLM Agent Platform (Kubernetes self-hosted, MIT, multi-provider). Maintenant OpenAI ship Symphony (SPEC plus référence Elixir, control plane issue tracker). Trois philosophies d'orchestration différentes releasées en neuf jours. Le bet spécifique de Symphony : l'orchestrateur d'agents devrait disparaître dans le PM tooling existant de l'équipe plutôt que d'être une nouvelle surface — framing de compétition différent du « on opère le cloud » (Routines) ou « tu opères le Kubernetes » (LiteLLM). Si le SPEC.md devient un vrai standard d'interop ou reste une convention OpenAI-only, ça dépend de si des implémentations community landent pour des agents non-Codex.
Lundi matin : si ton équipe roule déjà un issue tracker (Linear, GitHub Issues, Jira) et que vous considérez des agents code autonomes, le modèle de Symphony vaut un sérieux look — l'histoire d'intégration c'est « votre board existant, plus un agent qui watch ». L'implémentation de référence Elixir c'est le gate — si t'as pas d'expertise BEAM, soit tu traites ça comme un modèle à réimplémenter dans ton runtime préféré, soit tu attends des ports community. La question near-term : est-ce que Symphony devient un SPEC sur lequel Codex Mobile, Codex CLI et des agents tiers convergent, ou est-ce que ça reste un orchestrateur Codex-only. Watch le repo GitHub pour des PRs d'adapteurs non-Codex et le SPEC.md pour du langage protocole-vs-implémentation dans les quatre à six prochaines semaines.