Perché Muse Code tiene i suoi agent vivi per tutta la sessione
La scelta architetturale silenziosa dietro la velocità di Muse Code: background agent che persistono per l'intera sessione, invece di essere creati per ogni task e poi buttati via.
Il problema dello “spawn e getta”
La maggior parte dei tool di coding multi-agent segue la stessa ricetta: arriva un task, si crea un agent di supporto, gli si affida una fetta di lavoro, si raccoglie il risultato e lo si smonta. È un’astrazione pulita con un costo brutto. Ogni agent appena creato parte da zero: deve rileggersi la struttura del repository, riscoprire il sistema di build, reimparare le convenzioni del tuo codice. In una sessione con dieci task, quella tassa di raccolta contesto la paghi dieci volte.
E la tassa non è fatta solo di token. È latenza — ogni cold start ritarda il lavoro vero — ed è fatica di supervisione, perché un agent che ha dimenticato quello che aveva imparato un’ora fa ti fa le stesse domande due volte.
La risposta di Muse Code: la persistenza
Muse Code è costruito come un semplice loop dell’agent principale più un insieme di background agent asincroni — e quei background agent restano attivi per tutta la sessione. Non vengono creati per i singoli task. Ognuno è specializzato, continua ad accumulare contesto man mano che la sessione avanza, e decide da solo quando qualcosa merita di essere riportato all’agent principale.
Quest’ultimo dettaglio conta più di quanto sembri. I background agent non bloccano il loop principale in attesa di istruzioni, ma non lo inondano nemmeno di aggiornamenti di stato. Portano avanti i passi successivi in autonomia e comunicano quando serve davvero. La motivazione dichiarata da Meta è esattamente la coppia di costi vista sopra: la persistenza riduce la latenza, e riduce il bisogno di intervento umano sui task difficili e multi-step.
Worker in parallelo, reviewer sullo sfondo
In pratica lo vivi come una squadra con ruoli fissi, non come una coda di lavoratori interinali. I worker eseguono le modifiche in parallelo; i reviewer criticano continuamente l’output in background prima che arrivi a te. La formula del lancio — “multi-agent by default” — è precisa: la coordinazione non è una modalità da attivare, è il modo in cui gira ogni task. Consegni più in fretta non perché il singolo agent sia più veloce, ma perché il controllo qualità avviene in parallelo invece che come ripensamento finale.
Addestrato nel modello, non appiccicato sopra
C’è un motivo per cui questo design dell’harness funziona meglio con Muse Spark 1.2 di quanto farebbe un wrapper generico. Il modello è stato co-addestrato con l’harness di Muse Code: la sua ricetta di training ha ottimizzato esplicitamente il comportamento dei subagent, insieme agli obiettivi e alla compattazione del contesto. La divisione del lavoro tra un loop principale e specialisti persistenti non è un trucco di prompt engineering appoggiato sopra: il modello l’ha vista durante il training. Da lì arrivano le promesse di “meno retry, migliore uso dei tool”, e ne parliamo a fondo nel post su come è stato addestrato Muse Spark 1.2.
Quello che la persistenza non risolve
Agent longevi che modificano lo stesso repository in contemporanea sarebbero la ricetta perfetta per un disastro di merge — se condividessero la copia di lavoro. Non la condividono. Quando il lavoro va in fan-out, ogni agent figlio con permesso di scrittura riceve il proprio git worktree isolato, così il lavoro parallelo non collide mai sui file. Quel meccanismo di isolamento merita una spiegazione a parte: agent fan-out e git worktree. E quando vuoi sapere cosa hanno combinato davvero questi agent mentre non guardavi, l’event log append-only ha la risposta completa.