Por qué Muse Code mantiene vivos a sus agentes durante toda la sesión
La decisión de arquitectura silenciosa detrás de la velocidad de Muse Code: agentes en segundo plano que persisten durante toda la sesión, en lugar de crearse por tarea y tirarse a la basura.
El problema de crear y descartar
La mayoría de herramientas de programación multiagente siguen la misma receta: llega una tarea, se levanta un agente auxiliar, se le entrega un trozo del trabajo, se recoge el resultado y se destruye. Es una abstracción limpia con un coste feo. Cada agente recién creado parte de cero: tiene que releer la estructura del repositorio, redescubrir el sistema de build, reaprender las convenciones de tu código. En una sesión con diez tareas, ese peaje de recopilar contexto se paga diez veces.
Y el peaje no son solo tokens. Es latencia — cada arranque en frío retrasa el trabajo de verdad — y es esfuerzo de supervisión, porque un agente que olvidó lo que aprendió hace una hora te hace las mismas preguntas dos veces.
La respuesta de Muse Code: persistencia
Muse Code está construido como un bucle simple de agente principal más un conjunto de agentes asíncronos en segundo plano — y esos agentes de fondo permanecen activos durante toda la sesión. No se crean para tareas individuales. Cada uno está especializado, va acumulando contexto a medida que avanza la sesión, y decide por sí mismo cuándo algo merece reportarse al agente principal.
Ese último detalle importa más de lo que parece. Los agentes de fondo no bloquean el bucle principal esperando instrucciones, y tampoco lo inundan de actualizaciones de estado. Ejecutan los siguientes pasos de forma independiente y comunican cuando importa. La justificación que da Meta son exactamente los dos costes de arriba: la persistencia reduce la latencia, y reduce la necesidad de dirección humana en tareas difíciles de varios pasos.
Trabajadores en paralelo, revisores en segundo plano
En la práctica lo vives como un equipo con roles fijos, no como una cola de temporales. Los workers ejecutan cambios en paralelo; los revisores critican el resultado continuamente en segundo plano antes de que te llegue. El mensaje del lanzamiento — “multiagente por defecto” — es preciso: la coordinación no es un modo que activas, es cómo corre cada tarea. Entregas más rápido no porque ningún agente individual sea más rápido, sino porque el control de calidad ocurre en paralelo y no como una ocurrencia tardía.
Entrenado en el modelo, no atornillado encima
Hay una razón por la que este diseño de harness funciona mejor con Muse Spark 1.2 que un wrapper genérico de modelo. El modelo se co-entrenó con el harness de Muse Code: su receta de entrenamiento optimizó explícitamente el comportamiento de subagentes, junto con los objetivos y la compactación de contexto. La división del trabajo entre un bucle principal y especialistas persistentes no es un truco de prompt engineering pegado por encima; el modelo la vio durante el entrenamiento. De ahí salen las afirmaciones de “menos reintentos, mejor uso de herramientas”, y lo tratamos a fondo en nuestro post sobre cómo se entrenó Muse Spark 1.2.
Lo que la persistencia no resuelve
Agentes de larga vida editando el mismo repositorio a la vez serían la receta perfecta para desastres de merge — si compartieran copia de trabajo. No lo hacen. Cuando el trabajo se reparte, cada agente hijo con permiso de escritura recibe su propio git worktree aislado, así que el trabajo en paralelo nunca colisiona en los archivos. Ese mecanismo de aislamiento merece explicación propia: fan-out de agentes y git worktrees. Y cuando quieras saber qué hizo realmente cualquiera de estos agentes mientras no mirabas, el event log append-only tiene la respuesta completa.