OpenAI Symphony transforma orquestração de agentes de código em um plano de controle always-on
A OpenAI publicou o Symphony em 27 de abril de 2026 como spec open-source e repo de referência para rodar agentes de código continuamente contra uma fila de issues. O sinal importante não é um novo modelo. É a OpenAI tratando dispatch, retries, workspaces isolados e relatórios com prova de trabalho como infraestrutura de primeira classe para times de agentes.
openai/symphony junto de uma spec pública para um orquestrador contínuo que lê trabalho do tracker, sobe workspaces isolados, roda agentes de código e faz retry ou landing com regras explícitas.O movimento importante é o scheduler, não a narrativa de autonomia
A OpenAI descreve o Symphony como um serviço que lê trabalho do tracker continuamente, cria um workspace isolado por issue e roda uma sessão de agente dentro desse workspace. O repo e a spec colocam estrutura concreta em coisas que times costumam improvisar mal: claims, slots de worker, backoff, retry, regras de release e limites de concorrência por host.
Isso importa porque a dor operacional em agentes de código mudou. Quando o time passa de poucas sessões paralelas, o modelo deixa de ser o único limite. Coordenação vira vazamento. Humanos gastam tempo verificando se o run travou, se dois agentes tocaram a mesma fila, se o retry é seguro e se o output merece merge.
O Symphony transforma prova de trabalho em parte do workflow
O repo de referência enquadra a saída como algo maior que um patch. Ele fala de status de CI, feedback de PR review, análise de complexidade e evidência em walkthrough. Isso encaixa com o que o Codex já vinha sinalizando no desktop: sistemas úteis de agentes estão virando produtos de workflow, não só produtos de geração.
Para leitores do Token Robin Hood, essa é uma história de tokens mais forte que mais um benchmark de modelo. Um bom orquestrador reduz retries ociosos, coleta duplicada de contexto e overhead humano de supervisão. Um orquestrador ruim faz paralelismo parecer produtividade enquanto multiplica gasto escondido.
O que copiar e o que não copiar
As partes úteis são deliberadamente sem glamour: workspaces isolados, estados explícitos de orquestração, concorrência limitada, regras de backoff e superfícies de auditoria por issue. São essas peças que impedem uma fila de agentes de código de virar um centro de custo invisível.
A parte que não vale copiar cegamente é o romance da autonomia total. A própria OpenAI rotula o Symphony como preview para ambientes confiáveis. Essa é a leitura certa. Se o seu repo não tem testes fortes, critérios claros de aceite ou tarefas bem delimitadas, adicionar um orquestrador always-on vai amplificar processo ruim em vez de consertar.
O que leitores TRH devem fazer agora
Escolha uma trilha de engenharia que já tenha estrutura repetitiva: docs, bugs de baixo risco, updates de dependência ou issues de lacuna em testes. Defina estados da fila, uma política de retry, um pacote de prova de trabalho e um gate humano de merge. Depois compare trabalho landed por dia, carga de review e gasto de tokens contra o caminho atual com agentes manuais.
Se o orquestrador reduzir troca de contexto sem aumentar caos no review, escale. Se ele só gerar mais runs, o problema é agenda, não modelo.