OpenAI open-sourceó Symphony el 17 de mayo — un SPEC.md más una implementación de referencia en Elixir para orquestar agentes de código autónomos desde un task board de gestión de proyecto. Symphony vigila continuamente el board (issues, tareas, tickets, milestones), asigna cada tarea activa a un agente dedicado que corre autónomamente hasta que la tarea está hecha, y aflora el resultado para que un humano lo acepte o rechace. github.com/openai/symphony. El framing de OpenAI: "el costo de un agente cometiendo errores se reduce significativamente, ya que involucra principalmente revisar trabajo completado y rechazarlo" — revisión asíncrona en lote en vez de corrección interactiva en vuelo.
La elección arquitectónica que separa a Symphony de los frameworks de agentes existentes es el control plane. LangGraph modela el estado como un grafo que el orquestador posee; AutoGen lo trata como una conversación inter-agentes; CrewAI usa asignación explícita de rol/tarea. Symphony parasitea cualquier issue tracker que el equipo ya use como control plane — cada tarea que existe en el board del equipo es input de agente, y el output del agente fluye de vuelta como updates de ticket. Es un design point no trivial: elimina la UI de orquestador bespoke y reutiliza el workflow de revisión humana que los equipos ya operan. También restringe la superficie de tarea del agente a "lo que cabe en un issue", lo que es un prior útil. Detalle de implementación notable: Elixir, no Python o TypeScript. La semántica de árbol-de-supervisión OTP de Elixir mapea limpiamente a procesos por-agente de larga duración que necesitan reinicio y aislamiento.
Posiciona esto contra el resto de la semana de orquestadores de mayo. Anthropic lanzó Routines (workflows de Claude Code en el cloud de Anthropic, disparado por evento de repo, precio no publicado). BerriAI open-sourceó LiteLLM Agent Platform (Kubernetes auto-alojado, MIT, multi-proveedor). Ahora OpenAI lanza Symphony (SPEC más referencia en Elixir, control plane de issue tracker). Tres filosofías de orquestación diferentes lanzadas en nueve días. La apuesta específica de Symphony: el orquestador de agentes debería desaparecer en el tooling PM existente del equipo en vez de ser una superficie nueva — framing de competición diferente al "nosotros operamos el cloud" (Routines) o "tú operas el Kubernetes" (LiteLLM). Si el SPEC.md se convierte en un estándar real de interop o se queda como convención solo-de-OpenAI depende de si implementaciones de comunidad aterrizan para agentes no-Codex.
Lunes: si tu equipo ya corre un issue tracker (Linear, GitHub Issues, Jira) y han estado considerando agentes de código autónomos, el modelo de Symphony vale una mirada seria — la historia de integración es "tu board existente, más un agente vigilándolo". La implementación de referencia en Elixir es la puerta — si no tienes experiencia BEAM, o bien lo tratas como un modelo para reimplementar en tu runtime preferido o esperas ports de comunidad. La pregunta a corto plazo: si Symphony se vuelve un SPEC sobre el que Codex Mobile, Codex CLI y agentes terceros convergen, o si se queda como orquestador solo-de-Codex. Vigila el repo de GitHub para PRs de adaptadores no-Codex y el SPEC.md para lenguaje protocolo-vs-implementación en las próximas cuatro a seis semanas.