La comprensione di codebase aziendali di grandi dimensioni rappresenta uno dei compiti più complessi per gli agenti di intelligenza artificiale basati su modelli linguistici. Per rispondere a una singola domanda relativa a un repository può essere necessario compilare ed eseguire il software, seguire percorsi di esecuzione attraverso numerosi file, utilizzare diversi strumenti, verificare configurazioni e dipendenze e infine mettere insieme le prove raccolte durante un’attività che può protrarsi per decine di minuti. In questi scenari, distribuire il lavoro tra più agenti riduce il carico di contesto individuale, ma introduce un secondo problema: gli agenti devono essere in grado di comunicare mentre stanno ancora lavorando, perché una scoperta effettuata da uno di essi può modificare completamente il percorso investigativo degli altri.
AgentRadio è stato sviluppato dai ricercatori di Coral AI Labs insieme a ricercatori universitari proprio per affrontare questo limite. Il sistema introduce un livello asincrono di scambio dei messaggi che permette a più agenti impegnati contemporaneamente sulla stessa attività di condividere nuove informazioni durante l’esecuzione, senza dover interrompere necessariamente il lavoro principale o attendere una fase prestabilita di sincronizzazione. Il principio alla base del progetto è quello della “consapevolezza passiva”: ogni agente continua a lavorare sul proprio compito, ma può contemporaneamente ricevere informazioni prodotte dagli altri componenti del team e incorporarle nell’indagine in corso.
Il problema emerge soprattutto nei compiti a lungo termine. Un singolo agente tende infatti a seguire un percorso sequenziale all’interno del repository e, man mano che il contesto cresce, diventa più difficile rivedere il piano iniziale e propagare alle fasi precedenti le scoperte effettuate successivamente. Il modello può essere perfettamente in grado di svolgere ciascuna operazione richiesta, ma deve contemporaneamente mantenere attivi vincoli, dipendenze, ipotesi e prove eventualmente contraddittorie. Il limite diventa quindi quello della copertura complessiva del problema più che della capacità di eseguire singole istruzioni.
Uno dei benchmark utilizzati per misurare questa capacità è SWE-Atlas QnA, composto da domande formulate in linguaggio naturale relative a repository software reali. I task non possono essere risolti semplicemente leggendo o cercando il codice, perché richiedono agli agenti di eseguire il software, impartire comandi, osservare il comportamento dell’applicazione e ricostruire le relazioni tra differenti componenti. Nei test riportati per AgentRadio, una singola istanza di Claude Code basata su Claude Opus 4.6 ha completato correttamente il 32,3% delle attività, mentre l’impiego del più recente Opus 4.8 ha portato il risultato al 57,2%.
L’utilizzo di più agenti costituisce una soluzione relativamente semplice quando un’attività può essere scomposta in sotto-problemi indipendenti che vengono risolti separatamente e successivamente ricomposti. La comprensione di una codebase, però, difficilmente segue questo schema. Un file di configurazione individuato durante un’indagine, un comportamento inatteso osservato durante l’esecuzione oppure un bug scoperto in un modulo possono rendere immediatamente obsolete le ipotesi sulle quali sta lavorando un altro agente. La possibilità di coordinarsi soltanto alla fine del processo o a intervalli predefiniti rischia quindi di lasciare uno o più agenti impegnati per molto tempo su una direzione che è già stata invalidata.
I sistemi multi-agente tradizionali tendono a risolvere il coordinamento attraverso agenti che lavorano parallelamente ma in maniera indipendente oppure mediante protocolli sincronizzati per round. Nel primo caso i risultati vengono aggregati soltanto successivamente, mentre nel secondo gli agenti possono comunicare ma devono attendere un momento comune di sincronizzazione. Il limite del secondo approccio è evidente quando le scoperte hanno valore immediato: un agente che sta analizzando il comportamento di un’API potrebbe trovare informazioni che invalidano l’ipotesi seguita contemporaneamente dall’agente che sta studiando il sistema di archiviazione. Se questa informazione può essere trasmessa soltanto al termine del round, l’altro agente potrebbe completare inutilmente una lunga indagine basata su una premessa ormai errata.
Esistono anche architetture che introducono una forma parziale di asincronia, ad esempio nell’assegnazione delle attività, senza però fornire veri canali laterali peer-to-peer tra gli agenti. Altri sistemi utilizzano memorie condivise che devono essere consultate esplicitamente e obbligano quindi l’agente a interrompere temporaneamente il lavoro per controllare gli aggiornamenti. Il collo di bottiglia individuato dai ricercatori può essere riassunto nel fatto che, normalmente, un agente impegnato nell’esecuzione non può contemporaneamente rimanere in ascolto delle informazioni prodotte dagli altri.
AgentRadio interviene aggiungendo tre primitive di comunicazione al sistema che gestisce gli agenti di coding. create_thread consente di creare una conversazione tra gli agenti coinvolti, send_message inserisce un nuovo messaggio nel thread restituendo immediatamente il controllo all’agente che lo ha inviato, mentre wait_for_mention rimane in attesa di un messaggio diretto al chiamante. Quando arriva una menzione, insieme al messaggio viene fornita anche un’istantanea dei thread esistenti, così da permettere all’agente di interpretare rapidamente l’aggiornamento all’interno del contesto complessivo.
La caratteristica determinante è che wait_for_mention può essere eseguito come processo in background. L’agente non deve quindi scegliere tra svolgere il proprio lavoro e controllare continuamente la comunicazione con gli altri componenti del team. Il watcher rimane attivo mentre l’agente continua a utilizzare gli strumenti e a investigare il codice e gli aggiornamenti ricevuti possono emergere tra una fase di lavoro e quella successiva. È questo meccanismo a creare la consapevolezza passiva sulla quale si basa AgentRadio.
Il codice del progetto è disponibile pubblicamente su GitHub con licenza Apache 2.0 ed è stato progettato per funzionare come uno strato aggiuntivo rispetto agli agenti esistenti. L’implementazione non richiede quindi modifiche dirette a strumenti come Claude Code o Codex CLI. L’architettura comprende un server di messaggistica centrale, responsabile della conservazione delle discussioni, dei messaggi e delle menzioni, e una serie di script utilizzati dagli agenti per interagire con tale server attraverso le primitive di comunicazione.
L’unico requisito fondamentale è che l’ambiente nel quale viene eseguito l’agente consenta l’avvio di un comando shell in background. Il prompt di sistema indica agli agenti di mantenere in esecuzione il watcher e di utilizzare gli script disponibili per inviare messaggi. Un’integrazione reale richiede inoltre un adattatore che avvii i diversi worker, assegni loro un’identità, li colleghi al server condiviso e gestisca la sintesi conclusiva dei risultati. Questa logica viene aggiunta intorno all’agente di coding e non richiede interventi sul modello linguistico sottostante.
Per misurare il contributo della comunicazione asincrona, AgentRadio è stato valutato su 124 attività di SWE-Atlas QnA relative a undici repository di produzione e complessivamente associate a 1.306 criteri di valutazione. I compiti comprendevano progettazione di sistemi, analisi delle cause principali, sicurezza e integrazione delle API. Il protocollo sperimentale utilizzava quattro agenti e una sequenza di cinque fasi che consentiva di confrontare progressivamente una configurazione con singolo agente, un semplice aumento del budget computazionale, una divisione del lavoro tra agenti, una configurazione con pianificazione e revisione condivise e infine la versione completa dotata della comunicazione asincrona di AgentRadio.
Con Claude Opus 4.6, il singolo agente ha raggiunto un’accuratezza del 32,3%. Utilizzando sei esecuzioni indipendenti e scegliendo il risultato migliore, il valore è salito soltanto al 37,9%. Quattro agenti con semplice divisione del lavoro hanno ottenuto il 39,5%, mentre l’aggiunta di negoziazione, pianificazione congiunta e revisione incrociata con ricezione bloccante ha portato la percentuale al 51,6%. La configurazione completa AgentRadio, nella quale il cambiamento principale rispetto alla precedente consiste nell’introduzione della consapevolezza passiva attraverso wait_for_mention, ha raggiunto invece il 62,1%. Il risultato supera anche il 57,2% ottenuto dal singolo agente eseguito con il modello più recente Opus 4.8.
Una dinamica analoga è emersa utilizzando DeepSeek V4 Pro. Il singolo agente ha completato correttamente il 29% delle attività, mentre il sistema completo AgentRadio ha raggiunto il 50,8%. Il confronto tra la configurazione con negoziazione tradizionale e quella dotata di consapevolezza passiva mostra quindi che il miglioramento non dipende soltanto dall’impiego di più agenti, ma anche dal momento nel quale le informazioni vengono rese disponibili agli altri componenti del gruppo.
Uno degli esempi utilizzati per evidenziare questa differenza riguarda un’attività svolta su MinIO. Per arrivare alla soluzione era necessario verificare i log lato server relativi a ogni singola richiesta, requisito che gli agenti non avevano identificato nella pianificazione iniziale. Nella configurazione collaborativa priva di comunicazione asincrona due agenti hanno scoperto separatamente questa necessità durante l’esecuzione, ma non hanno potuto trasferire immediatamente l’informazione agli altri. Uno ha sostanzialmente abbandonato quella direzione e l’altro non è riuscito a portarla all’attenzione del team prima della revisione finale, che ha quindi convergito su una risposta sbagliata.
Con AgentRadio, la stessa scoperta è stata effettuata durante l’esecuzione ma le evidenze ricavate dai log sono state immediatamente comunicate agli altri agenti. Grazie al watcher in background, queste informazioni sono entrate nell’indagine degli altri componenti senza attendere la conclusione delle rispettive attività. Il risultato è passato a un punteggio perfetto di 16 criteri soddisfatti su 16. Il vantaggio non è derivato quindi dall’aggiunta di un ulteriore agente o di una nuova fase di revisione, ma dalla possibilità di consegnare una scoperta ai soggetti interessati prima che il suo valore operativo venisse perso.
Lo stesso principio può essere applicato alla gestione degli incidenti all’interno di infrastrutture aziendali. Un agente impegnato sull’analisi di un’API potrebbe trovare una prova che contraddice completamente l’ipotesi seguita dall’agente responsabile dello storage. Con una comunicazione disponibile soltanto a fine attività, il secondo potrebbe concludere un’intera analisi su una direzione sbagliata. La consapevolezza passiva consente invece di incorporare la nuova evidenza nel passaggio di lavoro successivo senza interrompere forzatamente un comando già in esecuzione.
Questa architettura comporta però un aumento significativo dei costi. Nei test dei ricercatori, un singolo agente basato su Opus ha richiesto in media 2,96 dollari di spesa API per attività, mentre la suite completa AgentRadio è arrivata a 19,45 dollari. L’aumento non può tuttavia essere interpretato semplicemente come acquisto di maggiore potenza di calcolo. Sei esecuzioni indipendenti di Opus, con un costo medio complessivo di 17,76 dollari per attività, hanno raggiunto soltanto il 37,9% di successo, molto lontano dal 62,1% ottenuto da AgentRadio con una spesa relativamente vicina. Il miglioramento deriva quindi dall’organizzazione e dal coordinamento del calcolo, non soltanto dalla quantità di token utilizzata.
La comunicazione introduce comunque anche nuovi rischi. Un messaggio può indirizzare un agente verso prove più solide, ma può allo stesso tempo distoglierlo da un percorso investigativo corretto. Per questo un team composto da più agenti non dovrebbe diventare automaticamente la configurazione standard per qualsiasi attività di sviluppo. L’utilità maggiore emerge quando esistono veri punti di separazione delle responsabilità, cioè situazioni nelle quali anche un ingegnere umano coinvolgerebbe un’altra persona perché il problema attraversa differenti aree di competenza, richiede un’ipotesi indipendente oppure comporta un rischio sufficientemente elevato da giustificare una verifica separata.
Le configurazioni coordinate risultano quindi più appropriate quando il lavoro può essere suddiviso ma le diverse parti rimangono strettamente interdipendenti, quando l’affidabilità di un singolo agente non è sufficiente e quando una risposta incompleta può generare costi rilevanti nelle fasi successive. Rientrano in questo scenario le analisi architetturali che coinvolgono un intero repository, l’esplorazione di sistemi legacy poco conosciuti, le indagini su incidenti che attraversano più servizi, le verifiche di sicurezza, le migrazioni di dipendenze e i refactoring che coinvolgono numerosi moduli.
Un singolo agente continua invece a essere una soluzione più semplice per interventi locali, delimitati e facilmente reversibili, come una modifica ben definita in un singolo file o la produzione di codice standard. Il passaggio a una struttura multi-agente diventa utile quando un unico contesto non riesce più a mantenere in modo affidabile la responsabilità dell’intero problema oppure quando il sistema dovrebbe contemporaneamente formulare e verificare in autonomia una conclusione particolarmente importante.
Il lavoro sperimentale su AgentRadio viene inoltre trasferito verso una soluzione commerciale chiamata Coral Code. Mentre il framework utilizzato nella ricerca prevede un gruppo fisso di quattro agenti organizzati secondo un protocollo a cinque fasi, Coral Code utilizza un modello più dinamico. L’ingegnere può iniziare con il normale agente di coding e introdurre successivamente capacità di analisi a livello di repository, responsabilità specialistiche e comunicazione tra agenti soltanto quando le evidenze emerse durante il lavoro lo rendono necessario. L’obiettivo è inserire il contesto del repository, gli specialisti e il livello di coordinamento intorno agli strumenti che gli sviluppatori utilizzano già, evitando di applicare una costosa architettura multi-agente a ogni attività.
L’evoluzione di questi sistemi lascia però aperto un problema ulteriore: la gestione dell’attenzione. AgentRadio rende possibile comunicare durante l’esecuzione, ma non decide automaticamente quanti agenti debbano partecipare a un’attività, quali informazioni meritino di interrompere o modificare il lavoro di un altro agente, chi debba ricevere ogni aggiornamento e quando le evidenze raccolte siano sufficientemente solide da giustificare una revisione del piano.
Se tutti gli agenti ricevessero ogni singola informazione, la comunicazione potrebbe rapidamente trasformarsi in rumore. Esiste inoltre il rischio opposto: se più agenti partono dalla stessa ipotesi sbagliata, una comunicazione più rapida può semplicemente propagare l’errore all’intero gruppo. La consapevolezza condivisa aumenta quindi la velocità con cui circola una scoperta, ma non può garantire che la scoperta corretta venga effettivamente formulata.
Questo limite è emerso anche in un caso di studio relativo alla piattaforma Grafana. Quattro dei nove criteri utilizzati per valutare la risposta richiedevano conclusioni negative, tra cui il riconoscimento del fatto che un selettore delle sorgenti dati non effettuasse automaticamente una determinata scelta. Gli agenti avevano eseguito i test necessari, ma nessuno aveva formulato esplicitamente l’ipotesi negativa richiesta. Sia il sistema tradizionale sia quello basato sulla comunicazione coordinata hanno quindi mancato gli stessi quattro criteri. Una rete di comunicazione può diffondere rapidamente un’idea generata da uno degli agenti, ma non può creare un concetto che nessun componente del team ha individuato.
Con l’aumento della durata e della complessità delle attività affidate agli agenti software, il coordinamento dovrà quindi evolvere oltre il semplice scambio di messaggi. I sistemi multi-agente destinati all’ingegneria del software dovranno essere in grado di assegnare dinamicamente le responsabilità, indirizzare le informazioni sulla base delle evidenze disponibili, risolvere eventuali conflitti tra conclusioni differenti, applicare limiti espliciti ai costi, gestire autorizzazioni e possibilità di rollback e stabilire punti chiari nei quali richiedere l’intervento umano.
A questo si aggiunge la necessità di mantenere una tracciabilità completa delle attività. Se più agenti contribuiscono alla stessa modifica o indagine, i responsabili dell’ingegneria devono poter ricostruire quale agente abbia prodotto una determinata evidenza, quali informazioni abbiano modificato il percorso di lavoro e perché una particolare conclusione o azione sia stata accettata. Man mano che gli agenti diventano capaci di lavorare autonomamente per periodi più lunghi, la comunicazione tra sistemi diventa quindi sempre più importante, ma aumenta parallelamente anche la necessità di rendere verificabili responsabilità, decisioni e passaggi intermedi.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)