A OpenAI open-sourceou o Symphony em 17 de maio — um SPEC.md mais uma implementação de referência em Elixir para orquestrar agentes de código autônomos a partir de um task board de gestão de projeto. Symphony observa continuamente o board (issues, tarefas, tickets, milestones), atribui cada tarefa ativa a um agente dedicado que roda autonomamente até que a tarefa esteja feita, e traz o resultado à tona para um humano aceitar ou rejeitar. github.com/openai/symphony. O framing da OpenAI: "o custo de um agente cometer erros é significativamente reduzido, já que envolve principalmente revisar trabalho completado e rejeitá-lo" — revisão assíncrona em lote em vez de correção interativa em voo.
A escolha arquitetural que separa Symphony dos frameworks de agentes existentes é o control plane. LangGraph modela estado como um grafo que o orquestrador possui; AutoGen trata como uma conversa entre agentes; CrewAI usa atribuição explícita de papel/tarefa. Symphony parasita qualquer issue tracker que o time já use como control plane — cada tarefa que existe no board do time é input de agente, e o output do agente flui de volta como updates de ticket. É um design point não trivial: elimina a UI de orquestrador bespoke e reusa o workflow de revisão humana que os times já operam. Também restringe a superfície de tarefa do agente a "o que cabe num issue", o que é um prior útil. Detalhe de implementação notável: Elixir, não Python ou TypeScript. A semântica de árvore-de-supervisão OTP do Elixir mapeia limpamente a processos por-agente de longa duração que precisam de restart e isolamento.
Posicione isso contra o resto da semana de orquestradores em maio. A Anthropic lançou Routines (workflows de Claude Code no cloud da Anthropic, disparado por evento de repo, preço não publicado). A BerriAI open-sourceou LiteLLM Agent Platform (Kubernetes auto-hospedado, MIT, multi-provedor). Agora a OpenAI lança Symphony (SPEC mais referência em Elixir, control plane de issue tracker). Três filosofias de orquestração diferentes lançadas em nove dias. A aposta específica do Symphony: o orquestrador de agentes deveria desaparecer dentro do tooling PM existente do time em vez de ser uma nova superfície — framing de competição diferente de "nós operamos o cloud" (Routines) ou "você opera o Kubernetes" (LiteLLM). Se o SPEC.md vira um padrão real de interop ou fica como convenção só-da-OpenAI depende de se implementações de comunidade aterrissam para agentes não-Codex.
Segunda-feira: se seu time já roda um issue tracker (Linear, GitHub Issues, Jira) e vocês vêm considerando agentes de código autônomos, o modelo do Symphony vale uma olhada séria — a história de integração é "seu board existente, mais um agente observando ele". A implementação de referência em Elixir é o portão — se você não tem expertise BEAM, ou trata como um modelo para reimplementar no seu runtime preferido ou espera ports da comunidade. A pergunta de curto prazo: se Symphony vira um SPEC sobre o qual Codex Mobile, Codex CLI e agentes terceiros convergem, ou se fica como orquestrador só-de-Codex. Fique de olho no repo do GitHub para PRs de adaptadores não-Codex e no SPEC.md para linguagem protocolo-vs-implementação nas próximas quatro a seis semanas.