Symphony: una especificación para convertir tickets en ejecuciones autónomas de código

Todo lo que hay que saber sobre openai/symphony: una especificación abierta y una implementación de referencia para leer trabajo desde un tablero, aislar cada incidencia en un workspace y operar agentes de programación sin supervisión interactiva continua.

Qué es Symphony

Symphony es una especificación de servicio para orquestar agentes de programación. Lee de forma continua el trabajo de un rastreador de incidencias —Linear en la primera versión de la especificación—, crea un espacio de trabajo aislado por incidencia y ejecuta allí una sesión de agente de código.

El repositorio de OpenAI no debe confundirse con un marco multiagente genérico ni con un producto SaaS acabado. La pieza central es SPEC.md, una especificación Draft v1 independiente del lenguaje; además incluye una implementación experimental de referencia en Elixir. OpenAI la describe como una “vista previa de ingeniería” de bajo perfil, destinada a entornos de confianza.

Su objetivo es cambiar el nivel de control: en lugar de supervisar sesiones individuales de Codex, un equipo gestiona tickets, estados de revisión y criterios de aceptación. Una ejecución exitosa puede detenerse en un estado definido por el flujo —por ejemplo, Human Review— y no necesariamente fusionar o completar el trabajo.

El origen: del harness engineering a gestionar trabajo

OpenAI anunció Symphony el 27 de abril de 2026. El artículo de lanzamiento lo sitúa como el paso posterior al harness engineering: una vez que un repositorio tiene pruebas, documentación, herramientas y guardrails adecuados para un agente, el cuello de botella pasa a ser coordinar muchas tareas sin alternar constantemente entre sesiones.

El equipo explica que primero utilizó este estilo para un proyecto interno desarrollado enteramente con código generado por Codex. Symphony transforma el tablero de proyecto —Linear en el ejemplo— en un plano de control para que un agente tome tickets, cree cambios, siga CI, trate comentarios de revisión y deje evidencia para la revisión humana.

El proyecto es oficialmente de OpenAI y se publica bajo licencia Apache-2.0. El README muestra alrededor de 24.700 estrellas, 2.400 bifurcaciones y 167 suscriptores en la consulta recuperada; son cifras cambiantes de GitHub, no una medida de adopción en producción.

Filosofía y principios

El ticket es la unidad de trabajo. Symphony decide elegibilidad, despacho, reintentos y recuperación a partir del estado del rastreador, no de sesiones abiertas manualmente.

Un workspace por incidencia. Los comandos del agente se limitan al directorio de trabajo asociado; el espacio se conserva entre ejecuciones y se limpia cuando la incidencia llega a un estado terminal.

Política versionada junto al código. WORKFLOW.md contiene el prompt y configuración del runtime, por lo que cada equipo puede versionar reglas de tickets, validación y entrega dentro de su repositorio.

Orquestación, no microgestión. El servicio programa y observa; el agente, mediante sus herramientas, suele efectuar comentarios, enlaces a PR y transiciones de ticket.

Guardrails del proyecto antes que autonomía. OpenAI sostiene que el patrón funciona mejor cuando el repositorio ya dispone de pruebas, documentación y controles automáticos sólidos.

Cómo funciona

La especificación divide el sistema en capas. Workflow Loader lee WORKFLOW.md; la capa de configuración valida valores y referencias de entorno; el adaptador del rastreador normaliza incidencias; el orquestador controla polling, concurrencia, reintentos y reconciliación; el gestor de workspaces prepara el directorio por ticket; y el agente se comunica con un servidor de aplicaciones de código mediante stdio.

Linear / issue tracker → Orquestador → workspace aislado por ticket
                                      → agente de código
                                      → CI, revisión y evidencia
                                      → estado de entrega definido en WORKFLOW.md

El servicio mantiene un único estado de orquestación en memoria, ejecuta el sondeo con concurrencia limitada, frena trabajos que dejan de ser elegibles y aplica backoff exponencial ante fallos transitorios. También debe ofrecer, como mínimo, registros estructurados para operar varias ejecuciones concurrentes.

Componentes principales

SPEC.md: contrato de comportamiento portátil y lenguaje neutral. Usa terminología RFC 2119 (MUST, SHOULD, etc.) y deja explícitas las decisiones que cada implementación debe definir.
WORKFLOW.md: política propia del repositorio: front matter YAML para configuración y cuerpo de prompt para instrucciones, validaciones y estado de entrega.
Adaptador de tracker: en v1, Linear aporta la fuente de incidencias, estados y metadatos; la especificación exige normalización antes de que el orquestador actúe.
Gestor de workspaces: genera rutas deterministas por incidencia, aplica hooks del ciclo de vida y conserva los espacios entre ejecuciones.
Agent runner: construye el prompt desde ticket y workflow, lanza el cliente del agente y devuelve actualizaciones al orquestador.
Superficie de estado: es opcional; puede ser terminal, panel u otra vista humana. La especificación no impone una UI rica.

El ecosistema

Symphony está diseñado para trabajar con el app server de Codex, aunque SPEC.md evita convertir sus detalles en un protocolo fijo y pide consultar la documentación generada o vigente de ese servidor.

El repositorio ofrece dos rutas: construir una implementación propia en el lenguaje que se prefiera a partir de la especificación, o probar la referencia experimental en Elixir. Esta separación es importante: la especificación es el activo principal; la referencia no debe tratarse como una solución universal terminada.

La comunidad ya ha creado interpretaciones. broomva/symphony se presenta como una implementación Rust que consulta Linear, GitHub o Markdown y despacha agentes en workspaces por ticket; es un proyecto independiente inspirado en la especificación de OpenAI, no software mantenido por OpenAI. También apareció Contrabass, otra implementación en Go presentada en Hacker News.

Guía rápida de uso

Preparación

El README recomienda adoptar primero prácticas de harness engineering: pruebas automáticas útiles, documentación actualizada, herramientas para inspeccionar CI y reglas claras sobre cómo se acepta un cambio.

Después hay dos opciones:

Pedir a un agente de programación que implemente Symphony según SPEC.md en el lenguaje elegido.
Usar la implementación de referencia y seguir elixir/README.md para preparar el entorno y ejecutar el binario con un WORKFLOW.md de proyecto.

Flujo habitual

Redactar WORKFLOW.md con estados elegibles, reglas, validaciones, herramientas y el punto de handoff humano.
Conectar Linear y las credenciales del host para el tracker y el agente.
Iniciar el servicio para que consulte las incidencias en la cadencia definida y reserve workspaces separados.
Dejar que el agente implemente, ejecute pruebas, cree o actualice el PR y procese comentarios según la política del repositorio.
Revisar el paquete de evidencia y aceptar, corregir o cancelar desde el flujo de trabajo elegido.

Trampas frecuentes y soluciones

Empezar con tickets ambiguos. OpenAI reconoce que no todas las tareas encajan: problemas con juicio fuerte o definición difusa siguen necesitando sesiones interactivas de ingeniería.
Asumir que el aislamiento de workspace equivale a sandbox completo. La especificación aísla directorios por incidencia, pero no exige controles fuertes de sandbox más allá del agente y el SO anfitrión.
Dejar la política fuera del repositorio. El propósito de WORKFLOW.md es que reglas, prompt y configuración evolucionen junto al código. Dos copias pueden crear confusión sobre la fuente de verdad; existe una discusión específica sobre ese punto.
Fusionar automáticamente sin una etapa de entrega. Symphony permite que el éxito termine en revisión humana; cada equipo debe definir qué controles habilitan una fusión.
Tratar credenciales del tracker como detalle menor. El agente puede operar tickets mediante herramientas nativas; los secretos deben proveerse por referencias del host y limitarse al mínimo necesario.

Seguridad y modelo de confianza

La especificación exige que cada implementación documente su postura de confianza y seguridad, pero no prescribe una política única de aprobaciones, sandbox u operador. Reconoce de forma expresa que algunas implementaciones apuntan a entornos confiables y otras requieren controles más estrictos.

Por diseño, Symphony es un planificador/runner y lector de tickets. Las escrituras del rastreador —transiciones, comentarios y enlaces de PR— suelen realizarlas las herramientas nativas del agente. Cuando las credenciales se entregan por referencias de secretos del host, el proceso hijo del agente no necesita una segunda autenticación directa con el tracker.

La práctica segura es por tanto separar entornos, limitar las credenciales, exigir CI y revisión humana antes de estados terminales, y no activar un flujo autónomo sobre repositorios o tableros no confiables. Son controles coherentes con la especificación y el aviso de preview, no sustituyen una certificación de seguridad de OpenAI.

Cómo lo recibió la comunidad

La recepción visible combina interés técnico y cautela. En Reddit, el anuncio en r/OpenAI obtuvo 44 votos y un comentario lo caracterizó como gestión de proyecto más que como “orquestación”; es una opinión individual, pero describe bien el cambio de nivel operativo que persigue el proyecto.

Un autor publicó una implementación Rust basada en la especificación y afirmó haber procesado 24 tickets mediante el ciclo de implementación, PR, revisión automatizada y aprobación humana. Es un informe personal no auditado, no una métrica oficial de Symphony.

Las discusiones de GitHub incluyen implementaciones derivadas, herramientas que generan WORKFLOW.md y hallazgos de seguridad para la referencia Elixir. Acreditan que hay experimentación sobre la especificación, no que dichas soluciones hayan sido evaluadas o aprobadas por OpenAI.

Symphony frente a otras propuestas

Propuesta	Coincidencia verificable	Diferencia verificable
Sesión interactiva de Codex	Ambas usan un agente de programación para modificar un repositorio.	Symphony toma trabajo de un tracker, programa ejecuciones persistentes y conserva una política de entrega versionada.
Automatización CI tradicional	Ambas reaccionan a estados y ejecutan procesos repetibles.	Symphony asigna a un agente una incidencia y un workspace, permitiéndole razonar y usar herramientas dentro de una política de repositorio.
`broomva/symphony`	Implementa el patrón de tickets, workspaces aislados y sesiones de agente.	Es una implementación comunitaria en Rust que amplía los orígenes de trabajo declarados; no es la referencia de OpenAI.
Contrabass	Se inspira en la especificación y usa la orquestación de agentes para tareas de ingeniería.	Es un proyecto Go/Charm Stack de terceros presentado como Show HN.

Casos de uso y a quién puede ayudar este repositorio

Equipos con tableros bien definidos que quieren convertir incidencias de bajo o medio riesgo en propuestas de cambio revisables.
Repositorios con buen harness —pruebas, CI, convenciones y documentación— que pueden dar al agente señales objetivas de éxito.
Equipos que sufren cambio de contexto al coordinar varias sesiones de agentes y prefieren controlar cola, estados y entregables.
Desarrolladores de plataformas internas que quieren implementar el patrón en otro lenguaje o tracker, tomando la especificación como contrato.

No es una solución genérica para cualquier backlog: las tareas ambiguas, de alto riesgo o que requieren juicio experto continuo siguen necesitando dirección humana directa.

Recursos

Repositorio: https://github.com/openai/symphony
Especificación: https://github.com/openai/symphony/blob/main/SPEC.md
Implementación Elixir: https://github.com/openai/symphony/tree/main/elixir
Anuncio de OpenAI: https://openai.com/index/open-source-codex-orchestration-symphony/
Discusiones: https://github.com/openai/symphony/discussions
Implementación comunitaria Rust: https://github.com/broomva/symphony

Nota: artículo elaborado con la especificación, repositorio, anuncio oficial y conversaciones públicas recuperadas el 17 de agosto de 2026. Symphony se declara Draft v1 y preview experimental; sus detalles pueden cambiar.