Symphony Mac es una app nativa para macOS inspirada en OpenAI Symphony. OpenAI planteó Symphony como una forma de orquestar agentes de software alrededor de tareas de trabajo. En este proyecto, esa idea se lleva al contexto que me interesaba más: issues de GitHub, repositorios reales y una app de escritorio local.
El repositorio del proyecto está aquí: pedrocid/SymphonyMac.
La pregunta de fondo es bastante concreta. Si un agente ya puede implementar cambios, revisar código o ejecutar tests, ¿cómo organizas todo eso para que no quede como una secuencia de comandos sueltos o conversaciones aisladas?
Symphony Mac intenta responder a esa pregunta con un pipeline explícito:
Implementar -> Code Review -> Testing -> Merge -> Done
Cada issue puede recorrer esas etapas con agentes separados, workspaces aislados y estado visible en la interfaz.
El dashboard principal de Symphony Mac convierte el trabajo del agente en algo visible: issues, etapas, estado y progreso real.
Qué problema intenta resolver
Hay muchas herramientas de IA para programación que funcionan bien para tareas puntuales. Les das una instrucción, generan código y tú decides qué hacer con el resultado. Eso es útil, pero deja fuera una parte importante del trabajo real.
Cuando trabajas con un issue de verdad, normalmente no basta con generar código. También necesitas:
- aislar el trabajo de otras tareas,
- abrir y seguir un pull request,
- revisar el resultado,
- ejecutar tests,
- manejar fallos parciales,
- decidir si se puede avanzar,
- y mantener una superficie clara de supervisión.
Ese es el hueco en el que entra Symphony Mac. No intenta reemplazar GitHub ni el editor. Intenta dar estructura operativa a trabajo ejecutado por agentes.
Cómo funciona
La app está construida con Tauri v2, backend en Rust y frontend en React. Para GitHub usa gh, así que opera sobre el mismo flujo que ya existe alrededor de repos, issues y PRs.
El modelo es bastante directo:
- Se selecciona un repositorio.
- La app lee los issues abiertos.
- Cada issue se convierte en una unidad de trabajo.
- Se crea un workspace aislado para esa tarea.
- Se lanza el agente correspondiente a la etapa actual.
- El resultado de esa etapa determina si se avanza, se reintenta o se detiene.
Lo importante es que el unit of work no es “un prompt”, sino un issue con estado, contexto y un pipeline alrededor.
Eso hace que la aplicación sea menos un chat con herramientas y más un orquestador.
Workspaces y repos locales
Una parte importante del diseño es el aislamiento. Cada issue trabaja en su propio workspace para evitar interferencias entre tareas concurrentes.
Al principio eso se apoyaba en clones aislados. Más adelante se añadió soporte para repos locales mediante git worktrees, que encaja mejor con un uso diario sobre repositorios que ya tienes en tu máquina.
Ese detalle cambia bastante la naturaleza de la app. Ya no depende solo de clonar y operar fuera de tu entorno, sino que puede trabajar cerca del repositorio real, con menos coste y menos fricción.
Me parece una decisión importante porque refuerza el carácter local del proyecto. Symphony Mac no intenta convertir el desarrollo en un servicio remoto abstracto. Intenta orquestarlo desde el escritorio, apoyándose en herramientas y repositorios que ya existen.
La vista de agentes activos muestra procesos reales, logs en streaming y estado en tiempo real.
Visibilidad y control
Otra parte central del proyecto es que todo el trabajo del agente queda expuesto. La app mantiene un tablero con etapas, una vista de agentes activos y logs persistentes para seguir lo que está ocurriendo.
Esto no es solo una cuestión visual. Cambia la forma en que se usa el sistema. Cuando el trabajo queda representado como estado y no como texto perdido en una sesión, es mucho más fácil responder a preguntas básicas:
- qué issue está ejecutándose,
- en qué etapa está,
- si el agente sigue activo o se ha quedado colgado,
- si el PR se abrió correctamente,
- o si una tarea falló en implementación, review, testing o merge.
La visibilidad también hace posible algo más importante: el control humano.
Autonomía graduable
Uno de los aspectos más útiles de Symphony Mac es que no asume un modelo único de autonomía.
La app puede ejecutar el pipeline de manera bastante automática, pero también permite introducir reglas de aprobación y avance manual entre etapas. Eso significa que no estás obligado a elegir entre dos extremos:
- o un agente completamente autónomo,
- o un proceso totalmente manual.
Puedes decidir qué partes delegar y en cuáles quieres supervisión explícita. En software real, ese tipo de control fino es más útil que la idea de una autonomía total y opaca.
No depende de una sola CLI
Otra decisión buena del proyecto es que la orquestación no está atada a un único agente. Symphony Mac soporta Claude Code y Codex, y además permite configurar comandos personalizados.
Eso importa porque el valor principal aquí no está en el proveedor concreto, sino en la estructura que organiza el trabajo:
- cómo se construye el prompt,
- qué etapa se ejecuta,
- dónde corre,
- qué contexto recibe,
- y qué ocurre cuando termina.
La app, en ese sentido, funciona como una capa de coordinación por encima del agente.
Cómo ha ido tomando forma
Revisando el historial del proyecto se ve una evolución bastante coherente. La base inicial era el pipeline, los workspaces, la UI y la integración con GitHub. Después fueron entrando capas más operativas:
- persistencia del estado,
- detección de agentes colgados,
- retries parciales,
- soporte multi-repo,
- approval gates,
- prompts configurables,
- contratos compartidos entre Rust y TypeScript,
- y soporte para worktrees y agentes personalizados.
No me interesa tanto esa lista por sí misma, sino por lo que dice del proyecto: la idea dejó de ser simplemente “ejecutar agentes” y pasó a ser mantener un sistema estable alrededor de ellos.
En resumen
La forma más precisa que encuentro de describir Symphony Mac es esta:
una app de escritorio para coordinar trabajo de desarrollo ejecutado por agentes sobre issues reales de GitHub.
Me interesa porque aborda una parte del problema que muchas veces queda fuera de las demos: no solo qué puede hacer un agente, sino cómo lo integras dentro de un flujo de trabajo reconocible, supervisable y útil.
Inspirarse en OpenAI Symphony tiene sentido precisamente por eso. No por copiar una interfaz o una marca, sino por tomar en serio la idea de que, si los agentes van a trabajar sobre software real, entonces necesitan algo más que un prompt. Necesitan estructura.
Y ahora mismo, eso es exactamente lo que Symphony Mac está intentando construir.