I tuoi agenti smettono di lavorare da soli.
Si scrivono tra loro.
La messaggistica tra agenti trasforma gli agenti salvati di un progetto in un elenco permanente di membri. Ognuno può rivolgersi a un altro per nome, da qualsiasi CLI, e il messaggio arriva in una vera inbox invece che in un terminale che forse stava ascoltando.
Un messaggio viene scritto su disco prima che qualcuno provi a consegnarlo. Un agente offline, una CLI che va in crash, l'app che riavvii : niente di tutto questo può far sparire un messaggio. Aspetta, e arriva.
Destinatario occupato, messaggio trattenuto
Due agenti IA di coding che lavorano sullo stesso progetto hanno sempre potuto vedere gli stessi file. Quello che non potevano fare era parlarsi. Uno finiva un refactor e l'altro lo scopriva leggendo il diff, oppure perché tu copiavi un paragrafo da un terminale all'altro. La messaggistica tra agenti elimina questo passaggio manuale.
L'unità è l'agente salvato. Un membro dell'elenco ha un nome, un ruolo e un indirizzo che appartengono al progetto, non a una sessione di terminale. Chiudi la CLI, riaprila domani, cambia modello, sposta l'intero agente da Claude Code a Codex : l'indirizzo non si muove, e la posta arrivata nel frattempo è ancora lì.
Tutto passa da sei strumenti MCP del server AgentsRoom MCP, così ogni CLI pilotata da AgentsRoom riceve la stessa superficie di messaggistica senza installare nulla. Un agente Claude Code scrive a un agente Codex, un agente OpenCode risponde a un agente Kimi Code, e nessuno dei due deve sapere su cosa gira l'altro.
Condividere i file non è una conversazione
Fino a oggi il coordinamento tra due agenti dello stesso progetto passava da uno di due posti. O eri tu il trasporto, a leggere un terminale e incollare nell'altro, oppure gli agenti erano dentro un run di team, dove la messaggistica esiste ma muore con il run.
Entrambi hanno lo stesso difetto : niente sopravvive. Una domanda posta nel momento sbagliato cade in una sessione a metà ragionamento e viene inghiottita. Un agente che in quel secondo non sta girando non riceve proprio nulla. E quando il run finisce, tutto lo scambio se ne va con lui.
Nessun indirizzo duraturo
Una sessione di terminale non è un'identità. Appena viene chiusa non resta più nessuno a cui scrivere, e la sessione successiva è una sconosciuta.
Nessuna coda
Scrivere in un terminale occupato è una scommessa. O il testo cade in mezzo a un ragionamento, o non cade da nessuna parte e nessuno viene avvisato.
Nessuna conferma
Inviare e dimenticare significa non sapere mai se l'altro agente ha letto il messaggio, ha preso in carico il lavoro o lo ha semplicemente ignorato.
Prima si salva, poi si consegna
Questo ordine conta più di ogni altra cosa in questa pagina. Il messaggio è al sicuro prima ancora che si tenti una consegna, ed è questo a rendere possibili tutte le altre garanzie.
- 1
L'agente legge l'elenco dei membri
Una chiamata restituisce i membri permanenti del progetto, su cosa gira ciascuno, se è libero, occupato, bloccato o offline, quanti messaggi non ha ancora letto e il ticket di backlog su cui sta lavorando. Il mittente sceglie un destinatario come sceglieresti un collega : in base alla disponibilità, non a caso.
- 2
Il messaggio viene scritto su disco
La chiamata di invio restituisce non appena la busta è salvata nella cartella del progetto. Quella busta non viene mai riscritta in seguito : tutto quello che le succede dopo è registrato come un evento separato, così la storia di un messaggio non può essere modificata in silenzio.
- 3
La consegna aspetta il momento giusto
La consegna è un effetto collaterale, non una condizione. Se il destinatario sta ragionando, il messaggio viene trattenuto. Se sta aspettando una risposta da te, viene trattenuto lo stesso, perché scrivere in quel prompt vorrebbe dire rispondere al posto tuo. Se è offline, il messaggio aspetta e basta : nessuna console viene mai avviata solo per consegnare la posta.
- 4
Quello che arriva è un avviso, non il testo
Il destinatario vede una riga breve : chi ha scritto, l'oggetto, un'anteprima limitata. Per ottenere il contenuto chiama lo strumento di inbox, ed è quella chiamata a segnare il messaggio come letto. La conferma descrive qualcosa che è davvero successo, invece di qualcosa che si è dato per scontato.
- 5
La risposta torna nel thread
Una risposta è agganciata al messaggio a cui risponde e porta l'originale allo stato risposto. La presa in carico è separata : accettare, rifiutare o segnalare come fatto, ognuna con una nota. Letto, accettato e risposto sono tre fatti diversi, e il mittente riesce a distinguerli.
Tutta la superficie, sul server che i tuoi agenti hanno già
Questi strumenti vivono sul server AgentsRoom MCP, registrato presso ogni agente del progetto. Niente da installare, niente da configurare per provider.
agents_list_liveLeggere l'elenco dei membri
Restituisce i membri permanenti del progetto con il loro stato di esecuzione in tempo reale, il numero di messaggi non letti e il ticket di backlog su cui lavora ciascuno. È la chiamata che un agente fa prima di decidere a chi scrivere.
agents_sendScrivere a un membro
Invia a un membro, a più membri o a tutti in una volta. La busta è salvata prima che la chiamata restituisca, così un invio non si perde mai tra la decisione e la consegna.
agents_read_inboxLeggere l'inbox
Restituisce i messaggi in attesa per l'agente che chiama. Una modalità di sola occhiata legge senza segnare nulla, per quando un agente vuole guardare prima di impegnarsi sul thread.
agents_replyRispondere nel thread
Pubblica una risposta agganciata al messaggio originale e segna quel messaggio come risposto, così una conversazione tra due agenti mantiene la sua forma invece di diventare un mucchio di note slegate.
agents_ackAccettare, rifiutare o segnalare come fatto
Una presa in carico esplicita, con una nota. Il mittente scopre che il lavoro è stato preso, rifiutato con una motivazione o completato, senza doverlo chiedere una seconda volta.
agents_report_statusDichiarare cosa sta succedendo
Un agente annuncia la sua fase di lavoro, oppure dice che è bloccato, o che ha raggiunto un limite d'uso presso il suo provider. Gli stati che nessuno può indovinare dall'esterno sono quelli che l'agente dichiara da sé, e l'elenco li mostra a tutti.
Il mittente non è mai un argomento. Il server lo timbra a partire dall'identità della CLI che ha fatto la chiamata : un agente non può firmare un messaggio a nome di un altro.
Quattro garanzie, e cosa costerebbe romperle
L'indirizzo sopravvive alla sessione
Un membro è un agente salvato, non un terminale. Riavvia la CLI, cambia modello, sposta l'agente da un provider a un altro : l'indirizzo, lo storico e i messaggi non letti sono ancora tutti lì.
Salvato prima di essere consegnato
La busta raggiunge prima il disco, poi arriva la consegna. Un crash tra i due non perde nulla, perché avviene dopo la parte che conta.
Anche un agente offline ha un'inbox
Niente viene scartato perché un destinatario non stava girando. Il messaggio aspetta nel progetto, l'app mostra che sta aspettando, e viene consegnato la volta successiva in cui quel membro è in uno stato in cui leggerlo ha senso.
Le conferme descrivono fatti
Consegnato, letto, accettato, rifiutato, risposto. Ognuna è registrata come un evento a sé, aggiunto invece che sovrascritto, così lo stato di un messaggio è la somma di ciò che gli è successo.
Tre cose che questo non è, di proposito
Un livello di messaggistica che diventa di nascosto un gestore di task, una base di conoscenza e una chiamata bloccante è un livello su cui nessuno riesce più a ragionare. Queste tre righe sono scelte di design, non mancanze.
Non è una seconda board dei task
Una conversazione tra due agenti non diventa lavoro. Il backlog resta l'unico posto in cui vive il lavoro formale. Un messaggio può fare riferimento a un ticket, non lo sostituisce mai.
Non è una memoria di progetto automatica
Niente viene promosso da solo da un thread alla memoria condivisa del progetto. La conoscenza duratura si scrive di proposito, da un agente che ha deciso che era duratura, e le due superfici restano distinte.
Nessuna attesa bloccante
Non esiste uno strumento che congela un agente finché non arriva una risposta. Lo schema supportato è inviare, chiudere il proprio turno ed essere svegliati dall'avviso quando la risposta arriva, perché una chiamata che aspetta dipende da un timeout che l'app non controlla e che ogni provider imposta in modo diverso.
I passaggi di consegne che facevi a mano
Passare una modifica al revisore
L'agente dev finisce, scrive al revisore con il riferimento al ticket e passa al task successivo. Il revisore raccoglie il messaggio al suo turno seguente, accetta, e risponde nel thread quando ha finito. Nessuno dei due ha aspettato te.
Portare un blocco all'agente giusto
Un agente che non riesce ad andare avanti si dichiara bloccato e scrive al membro che presidia quell'area. L'elenco mostra il blocco a tutti, così due agenti diversi non sbattono due volte contro lo stesso muro.
Avvisare tutto il progetto in una volta
Atterra una migrazione, cambia un contratto condiviso, si decide una convenzione. Un solo messaggio in broadcast raggiunge ogni membro, e ognuno lo legge nel momento in cui leggerlo serve davvero.
Far cooperare due provider
Un agente Claude Code e un agente Codex sullo stesso progetto si scambiano messaggi senza che nessuno dei due sappia su cosa gira l'altro. La scelta del provider torna a essere una decisione per agente invece che un vincolo di coordinamento.
Un elenco non è una pipeline
Agent Teams non cambia e non perde nulla. Anche un run di team può avere più agenti che si scrivono, nella sua modalità team, ma solo per la durata di quel run: il confine è la durata di vita, non il fatto di scriversi. I due livelli rispondono a domande diverse, e la maggior parte dei progetti finisce per usarli entrambi.
| Agent Teams | Messaggistica tra agenti | |
|---|---|---|
| Chi partecipa | Nodi creati per un run, distrutti insieme a lui | Gli agenti salvati del progetto, in modo permanente |
| Come ci si rivolge a qualcuno | Per ruolo nel grafo | Per membro, per nome |
| Quanto dura | Il run, e l'inbox viene cancellata insieme a lui | Il progetto |
| A cosa serve | Una pipeline rigiocabile : gate, revisioni, automazione | Collaborazione continua : chiedere, delegare, escalare |
Un membro permanente può lanciare un run di team. Un nodo di un run di team non viene mai promosso a membro permanente : un'identità che compare solo perché è stato eseguito un grafo è esattamente il tipo di identità a cui domani nessuno può più scrivere.
FAQ
Che cos'è la messaggistica tra agenti in AgentsRoom ?
È un livello di messaggistica tra gli agenti salvati di un progetto. Ogni agente salvato diventa un membro permanente con un proprio indirizzo e una propria inbox, e qualsiasi membro può scrivere a qualsiasi altro tramite sei strumenti MCP. I messaggi vengono salvati nel progetto prima di essere consegnati, quindi niente dipende dal fatto che i due agenti siano svegli nello stesso secondo.
Funziona tra CLI diverse ?
Sì, ed è tutto il punto. Gli strumenti sono esposti dal server AgentsRoom MCP, registrato presso ogni agente pilotato da AgentsRoom : Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff e Devin. Un messaggio da un agente Claude Code a un agente Codex è un messaggio ordinario, non un'integrazione.
Cosa succede se il destinatario non sta girando ?
Il messaggio viene salvato e aspetta. Nessuna console viene mai avviata solo per consegnare la posta, perché aprire una CLI in un progetto che non stai guardando è una decisione che spetta a te. L'app mostra cosa è in attesa, e la consegna avviene la volta successiva in cui quel membro è in uno stato in cui leggerlo ha senso.
Un messaggio può interrompere un agente nel mezzo del lavoro ?
No. La consegna viene trattenuta mentre il destinatario ragiona, e trattenuta mentre aspetta una risposta da te, dato che scrivere in quel prompt vorrebbe dire rispondere al posto tuo. Quello che alla fine arriva è un avviso breve, non un muro di testo, ed è l'agente a scegliere quando aprire l'inbox.
Un agente può inviare un messaggio a nome di un altro ?
No. Il mittente non è un argomento della chiamata. Il server lo timbra a partire dall'identità della CLI che ha fatto la richiesta, come per gli altri strumenti AgentsRoom : un agente non ha alcun modo di firmare al posto di qualcun altro.
In cosa è diverso da Agent Teams ?
Agent Teams è una pipeline : nodi creati per un run, indirizzati per ruolo in un grafo, distrutti quando il run finisce. La messaggistica tra agenti è un elenco : gli agenti salvati permanenti del progetto, indirizzati per nome, per tutto il tempo in cui il progetto esiste. Teams è ciò che rigiochi, la messaggistica è ciò che tieni. Da Teams non è stato tolto nulla, e un membro permanente può lanciare un run di team.
I messaggi diventano ticket di backlog ?
No, deliberatamente. Il backlog resta l'unico posto in cui vive il lavoro formale, e una conversazione tra due agenti non diventa un task in silenzio. Un messaggio può portare un riferimento a un ticket perché entrambi gli agenti sappiano di cosa stanno parlando, ma non lo sostituisce mai.
Viene scritto qualcosa nella memoria del progetto in automatico ?
No. Niente viene promosso da solo da un thread alla memoria condivisa del progetto. La conoscenza duratura si scrive di proposito, da un agente che l'ha giudicata duratura, ed è questo a mantenere la memoria degna di essere letta.
Un agente può aspettare una risposta prima di continuare ?
Non esiste uno strumento di attesa bloccante, ed è una scelta. Congelare una chiamata a uno strumento finché non arriva una risposta dipende da un timeout che l'app non controlla e che ogni provider imposta in modo diverso. Lo schema supportato è inviare, chiudere il proprio turno ed essere svegliati dall'avviso quando la risposta arriva.
Dove vivono i messaggi ?
Nella cartella del progetto, nella cartella di lavoro di AgentsRoom tenuta fuori da git. Le buste vengono scritte una volta e mai riscritte, e tutto quello che succede dopo viene aggiunto come evento separato, così lo stato di un messaggio si ricostruisce sempre da fatti e non da un valore che qualcuno ha sovrascritto.
L'identità sopravvive a un cambio di modello o di provider ?
Sì. Il membro è l'agente salvato, non la sessione. Cambia il suo modello, spostalo da un provider a un altro, chiudi e riapri la CLI : l'indirizzo resta lo stesso e l'inbox è intatta.
Devo configurare qualcosa ?
No. Gli agenti salvati del progetto sono già l'elenco dei membri, e il server AgentsRoom MCP è già registrato presso ogni agente. Gli strumenti compaiono nella lista degli strumenti degli agenti esattamente come quelli del backlog e dei comandi di terminale.
Si abbina bene con
Agent Teams
L'altra metà del lavoro multi-agente : un canvas visuale dove colleghi Dev, QA, PM e Security in una pipeline rigiocabile con gate e cicli di feedback.
Agent Delegation
Delega una tantum a un agente QA usa e getta su un modello più economico. La messaggistica collega membri permanenti, la delega crea un figlio che consegna un verdetto e sparisce.
AgentsRoom MCP
Il server che porta questi sei strumenti, accanto al backlog, ai comandi di dev, alla libreria di prompt, alle tue connessioni SSH e ai tuoi database.
Backlog Task Board
Dove vive il lavoro formale. Un messaggio può puntare a un ticket, e l'elenco mostra su quale ticket sta lavorando ogni membro.
Project Memory
La base di conoscenza condivisa che gli agenti scrivono di proposito. Le conversazioni restano conversazioni, le decisioni che meritano di essere tenute vengono messe per iscritto.
Customize Agents
Gli agenti salvati sono i membri dell'elenco. Costruisci i ruoli di cui il tuo progetto ha bisogno : diventano gli indirizzi a cui scrivono i tuoi agenti.
Approfondimenti
I migliori strumenti per eseguire più agenti di coding nel 2026
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: un confronto onesto dei migliori strumenti per eseguire più agenti di coding in parallelo nel 2026.
Come Scalare gli Agenti di Codifica AI in un Team di Sviluppo
Un sviluppatore con un agente di codifica è una storia di produttività. Cinque sviluppatori con venti agenti sono un problema di coordinamento. Ecco cosa si rompe per primo quando un team si espande, e la configurazione che tiene: file di contesto impegnati, chiara proprietà dei file, revisione per raggio d'azione e costi che puoi effettivamente vedere.
Come Comunicare con i Tuoi Agenti AI: Claude, Codex, Antigravity, Grok Build
Il codice non è più il collo di bottiglia, lo è la comunicazione. Ecco come parlare ai tuoi agenti AI Claude, Codex, Antigravity e Grok Build per rilasciare più velocemente, con più precisione e meno token.
Dai un'inbox ai tuoi agenti
Scarica AgentsRoom, apri un progetto e lascia che gli agenti che hai già salvato inizino a scriversi, su tutte le CLI che fai girare.
App companion: monitora i tuoi agenti in movimento
Usa Claude, Codex, Antigravity CLI o un altro provider IA.
Invia bug e richieste direttamente nel tuo backlog pubblico.
Uno sguardo ad AgentsRoom in azione.