Diseñando una “productora” de agentes para generar música 8-bit
ROSEWT
Nakato
La generación automática de música no es un territorio nuevo. Desde los primeros sintetizadores hasta la irrupción de los LLMs, siempre ha habido ingenieros intentando componer canciones sin saber leer una partitura. Curiosidad, audacia, o una mezcla honesta de ambas: en el fondo, muchos de nosotros somos uno de ellos.
El enfoque más extendido hoy es deceptivamente simple: construyes un agente, le pasas un prompt, y él hace "la magia" —compone de principio a fin, llama las herramientas disponibles, y listo. Y funciona... hasta que no funciona. Hasta que te escribe un poema. Hasta que pides un MIDI limpio, un loop que no canse o un MP3 renderizado correctamente, y el sistema empieza a comportarse de formas difíciles de explicar y aún más difíciles de depurar.
El desafío inicial no está en la música. Está en el diseño.
Cuando el objetivo final es producir una canción —un MP3, un WAV, lo que sea— a partir de lenguaje natural, pasando por un MIDI generado en el camino, ya no estás resolviendo una sola tarea. Estás interpretando requisitos, decidiendo estructura, explorando ideas, eligiendo una dirección artística, ajustando loops, diseñando timbres y ejecutando pasos técnicos muy específicos. Todo al mismo tiempo.
Meter todo eso en un único agente produce, casi invariablemente, dos consecuencias: resultados inconsistentes y un tool calling que falla de formas creativas. La raíz del problema es más conceptual que técnica: estás mezclando creatividad, toma de decisiones y ejecución en el mismo lugar, sin separación de responsabilidades.
En una productora pequeña los roles son claros. Alguien define el brief, alguien propone ideas, alguien decide la dirección, alguien produce el arreglo, alguien se encarga de los detalles técnicos. Nadie hace todo a la vez.
Apliqué esa misma lógica al diseño del sistema. Separé el flujo en agentes especializados:
Un agente que convierte el input humano en un brief estructurado.
Uno que propone varias ideas conceptuales.
Uno que evalúa y elige una.
Uno que construye el arreglo musical.
Uno que define la instrumentación.
Y uno —solo uno— responsable de escribir el MIDI y renderizar el audio.
Sin magia. Solo separación de responsabilidades.
Los agentes no se "entienden" hablando libremente entre sí. Se comunican a través de estructuras de datos claras y explícitas: brief, concepto, arreglo, instrumentación, resultado. Cada paso recibe algo bien definido y entrega algo igualmente bien definido.
El flujo completo lo gobierna un orquestador implementado en código. No es creativo. No toma decisiones artísticas. Solo ejecuta pasos en orden, guarda artefactos intermedios y decide qué repetir cuando algo falla. Y eso, lejos de ser una limitación, fue la decisión más importante del diseño: la creatividad no debería controlar el flujo de ejecución.
Este enfoque tiene costos reales. Es más lento que un solo prompt. Requiere más trabajo inicial. No maximiza la "creatividad libre" que a veces seduce en los demos de agentes.
Pero a cambio ofrece algo más valioso en producción: resultados reproducibles, fallos fáciles de aislar y depurar, loops que funcionan de verdad, y un sistema que no colapsa cada vez que se le pide un MP3.
Este patrón no está atado al mundo del audio. Es una forma de pensar el diseño de sistemas para cualquier tarea que combine creatividad con entregables técnicos: generación de contenido, diseño asistido, escritura estructurada, síntesis de datos.
Si necesitas algo creativo y confiable, el camino no es encontrar el prompt perfecto. Es diseñar un proceso.
Un solo agente puede generar algo bonito. Un sistema bien diseñado puede generar algo usable. Y aunque ese proceso pierda algo de la espontaneidad que hace atractivo el vibeAnithing, gana lo que más importa cuando el trabajo tiene que llegar a producción: que funcione.