Quando gli agenti diventano colleghi: l'idea dietro Buzz

Di Buzz ho già scritto, allora con un focus chiaro su Shared Compute e la gestione condivisa dei modelli. Quella era per me inizialmente la parte più affascinante e insolita del progetto. Più mi occupo di Buzz, però, più diventa interessante lo spazio di lavoro in sé. Per questo l’ho provato anche in un piccolo setup.

Il motivo è anche un problema che negli ultimi mesi sento sempre più chiaramente. Il mio lavoro con l’IA è diventato non solo più veloce, ma anche più disordinato. Codex lavora su un repository, Claude Code verifica una seconda idea, un altro agente raccoglie informazioni, e in mezzo a tutto questo girano terminale, browser, email e diverse chat. Ogni agente può essere utile di per sé. Il problema nasce ai passaggi. Il contesto va copiato, le decisioni vanno ripetute e i risultati vanno unificati manualmente.

È esattamente qui che interviene Buzz. Il progetto open source viene da Block, l’azienda guidata dal co-fondatore di Twitter Jack Dorsey e dietro Square. Non vuole costruire l’ennesimo assistente IA. Buzz crea uno spazio di lavoro condiviso in cui persone e agenti usano gli stessi channel, thread, progetti e protocolli. Un agente Codex può creare un piano, Claude Code può criticarlo, una persona può prendere la decisione e l’agente successivo può trasformarla in una modifica nel repository. L’intera catena resta visibile nello stesso spazio.

Il termine rapido “Slack-killer” per me è riduttivo. Buzz mostra una possibile forma di lavoro per team con molti agenti. Allo stesso tempo è ancora giovane, affamato di risorse e più impegnativo dal punto di vista della sicurezza di quanto l’interfaccia amichevole lasci intuire. Proprio questo mix di grande idea e stadio di sviluppo precoce rende interessante uno sguardo più approfondito.

Il vero problema non è il modello

La maggior parte degli strumenti IA è nata come relazione tra una persona e un agente. Apro Codex, inserisco un compito e ricevo un risultato. Poi apro Claude Code, spiego di nuovo lo stesso contesto e chiedo una seconda opinione. Per compiti singoli funziona bene. In un team o con più agenti in parallelo, però, nasce un nuovo problema di coordinamento.

Conosco esattamente questo problema dalla mia quotidianità. Claude Code, Codex, Hermes, browser, chat e diversi terminali girano fianco a fianco. I registri delle sessioni migrano da uno strumento all’altro. Un agente conosce le note della riunione, un altro il repository e un terzo gli accessi o le skill necessarie. Ognuno ha un frammento, ma nessuno ha lo stato di lavoro condiviso.

Le dashboard mission control risolvono solo in parte. Magari mostrano che cinque agenti sono attivi. Ma non creano ancora un luogo comprensibile in comune dove incarico, discussione, stato intermedio, review e decisione restano insieme. Buzz non parte quindi da una lista agenti più bella, ma dallo spazio di lavoro stesso.

Gli agenti sono membri, non bot appiccicati

A prima vista Buzz sembra familiare. Ci sono community, channel pubblici e privati, thread, messaggi diretti, forum, ricerca, huddle e un’app mobile. La differenza decisiva rispetto a una normale integrazione Slack sta sotto la superficie.

In Buzz un agente è un membro a sé stante. Possiede un profilo, una coppia di chiavi crittografiche, appartenenze ai channel e un proprio audit trail. I suoi messaggi appaiono sotto la sua identità. Grazie a questo si può vedere in seguito non solo che “l’IA” ha fatto qualcosa. Diventa visibile quale agente ha agito, in quale channel ha ricevuto l’incarico e quale persona o altro agente lo ha attivato.

Detto così sembra un piccolo cambiamento nella gestione utenti. Per il lavoro reale, però, è centrale. Un bot Slack di solito dipende da un’integrazione e aspetta di essere menzionato da una persona. Due bot di fornitori diversi normalmente non sanno nulla l’uno dell’altro. In Buzz gli agenti possono rivolgersi ad altri agenti, passare incarichi e discutere i loro risultati nello stesso thread. Codex e Claude Code non diventano così un sistema unico. Ottengono però uno spazio di comunicazione condiviso.

Buzz non porta automaticamente con sé tutta l’intelligenza. Lo spazio di lavoro collega i cosiddetti harness e modelli che girano già localmente, su un server o tramite un fornitore. Secondo lo stato attuale del progetto ne fanno parte, tra gli altri, Codex, Claude Code e Goose. Altri agenti possono essere collegati tramite interfacce aperte. È un modello bring-your-own-agent: Buzz coordina, l’agente in questione pensa e agisce con i propri tool, skill, accessi e costi di modello.

Il relay è lo stato di lavoro condiviso

Dal punto di vista tecnico Buzz è composto da più parti. L’app desktop è l’interfaccia. Una community è lo spazio di lavoro vero e proprio. Il Buzz Relay memorizza e distribuisce i suoi messaggi, membri, agenti, regole, media, dati di ricerca, workflow ed eventi Git. Gli agenti possono lavorare sulla stessa macchina dell’app desktop, su un server sempre attivo o su una macchina completamente diversa.

Come protocollo Buzz usa Nostr. Persone e agenti firmano gli eventi con le proprie chiavi private. Il relay verifica identità e appartenenza, salva gli event e li distribuisce ai client autorizzati. Questo non trasforma però Buzz in una magica rete peer-to-peer. Il relay è la fonte centrale di una community. Non c’è replica automatica tra relay, e i messaggi restano sul relay su cui sono stati inviati.

Questa costruzione ha due conseguenze interessanti. L’identità non appartiene semplicemente a un account Slack centrale, ma si basa su una propria coppia di chiavi. Allo stesso tempo un team può gestire da sé lo spazio di lavoro. Chi vuole prima solo testare può usare una community ospitata da Block. Chi vuole controllare da sé conservazione dei dati, disponibilità e backup gestisce il relay su infrastruttura propria.

L’architettura server attuale usa componenti noti: PostgreSQL per event e ricerca full-text, Redis per pub/sub e storage compatibile S3 per i media. Non è un piccolo servizio da dimenticare dopo l’installazione. Un relay auto-gestito richiede TLS, aggiornamenti, backup, monitoring e una gestione pulita delle chiavi.

Perché il contesto condiviso è così prezioso

L’idea più forte di Buzz è il contesto duraturo e visibile in comune. Un progetto non è più fatto di un messaggio chat su Slack, una sessione agente separata, una pull request su GitHub e una decisione in una videoconferenza. Buzz cerca di riunire queste tracce in uno spazio di eventi unico.

Questo è particolarmente utile quando diversi agenti hanno punti di forza diversi. Un flusso realistico può essere così:

1. Una persona descrive nel channel del progetto l’obiettivo e i limiti.
2. Un agente di ricerca raccoglie informazioni e documenta le sue fonti.
3. Un secondo agente attacca i punti deboli e cerca controargomenti.
4. Codex o Claude Code crea un piano concreto.
5. Un altro agente verifica il piano per sicurezza, test mancanti o assunzioni poco chiare.
6. Dopo l’approvazione umana, la modifica viene realizzata in un worktree separato.
7. Diff, risultati dei test, review e decisione restano rintracciabili nel channel corrispondente.

Questo schema è particolarmente interessante nelle review adversarial. Un modello riceve esplicitamente il ruolo di attaccare un piano di prodotto o un’implementazione. Un secondo modello deve difendere o migliorare le decisioni. Poiché entrambi vedono il thread completo, nasce un confronto reale con lo stato di lavoro esistente e non solo una review isolata di un testo copiato.

Anche per i processi di contenuto e business questo schema è interessante. Un agente fa ricerca sui temi, un secondo scrive, un terzo redige. Metriche o nuove notizie possono confluire regolarmente in un channel, così che persone e agenti possano discutere insieme l’evoluzione. Gli huddle vanno un passo oltre: persone e agenti parlano in una conferenza audio, la conversazione viene trascritta in testo e può poi trasformarsi in incarichi concreti.

Questo è il punto in cui Buzz diventa più di una chat di gruppo. Il channel non è solo un luogo di comunicazione. Diventa un registro di lavoro tracciabile.

Buzz vuole sostituire anche GitHub

Buzz integra repository Git, patch, review ed eventi di stato nello stesso spazio di lavoro. Il relay può ospitare i repository stesso. Gli agenti possono usare worktree, lavorare separatamente su varianti, mettere a disposizione le modifiche come patch e discutere le review nel contesto del progetto.

La visione dietro è forte: un feature branch diventa uno spazio. Lì non ci sono solo i commit, ma anche la discussione sul perché una modifica era necessaria, quali alternative sono state scartate, cosa ha segnalato la CI e chi ha approvato il merge. Proprio nel codice generato in modo agentico questa storia di origine oggi manca spesso.

Ciononostante non darei ancora per spacciato GitHub in modo affrettato. GitHub non è solo storage Git, ma un ecosistema cresciuto in anni per diritti, review, CI/CD, scansioni di sicurezza, release, integrazioni e collaborazione esterna. Buzz ha basi Git funzionanti e un approccio forge interessante. Lo stato del progetto stesso distingue però chiaramente tra parti già funzionanti, funzioni ancora da collegare e visione. Per repository critici un impiego graduale è più ragionevole di una migrazione immediata.

Il mio primo test con Buzz

Ho iniziato consapevolmente in piccolo: una community propria, un channel e due agenti con ruoli chiaramente separati. Codex doveva creare un piano tecnico, Claude Code doveva attaccare assunzioni, falle di sicurezza e complessità inutile. Credenziali di produzione, dati clienti e repository sensibili sono rimasti fuori. Volevo prima testare la collaborazione e non l’autonomia massima.

Il primo incarico aperto era troppo impreciso. Entrambi gli agenti hanno iniziato a pianificare, hanno reagito l’uno all’altro e a un certo punto hanno aspettato il prossimo impulso. È stato un buon promemoria del fatto che un channel condiviso non sostituisce ancora un’orchestrazione. Con l’istruzione chiara “Codex crea il piano, Claude lo verifica, poi aspettate l’approvazione” il flusso è diventato molto più tranquillo e tracciabile. Più agenti non sostituiscono una definizione di processo.

Ciò che mi ha convinto di più non è stata una risposta singola spettacolare, ma l’assenza di rotture nel mezzo. Entrambi gli agenti vedevano lo stesso thread, la critica restava accanto al piano originale, e potevo in ogni momento capire chi stava lavorando. Non ho dovuto copiare testo tra finestre né spiegare di nuovo la storia pregressa a un secondo agente. Proprio in questo sta per me il vero valore di Buzz.

Per lo sviluppo software intensivo il lavoro diretto in Codex o Claude Code è comunque rimasto più veloce. Buzz aggiunge comunicazione, protocollazione e contesto condiviso. Questo strato costa tempo e token. Ogni agente aggiuntivo possiede una sessione propria, e una storia estesa del channel può essere elaborata più volte con più modelli. Per una lunga sessione di coding continuerei quindi a usare l’harness nativo e userei Buzz piuttosto per pianificazione, passaggi di consegna e review.

Non ho ancora testato abbastanza a fondo workflow, huddle più lunghi, modelli locali e più agenti remoti in esecuzione continua. È proprio lì che Buzz deve dimostrare nella quotidianità che gli incarichi non sono solo visibili in modo elegante, ma vengono anche portati a termine in modo affidabile. Il software è precedente alla versione 1.0 e in alcuni punti si sente di conseguenza giovane. Per gli esperimenti va bene. I flussi centrali richiedono però ancora controllo, logica di ripetizione e una via di ritorno manuale chiara.

Il contesto condiviso è anche un confine di sicurezza

Ciò che rende Buzz utile ne aumenta allo stesso tempo la superficie di attacco. Un agente Codex, Claude Code o Hermes collegato porta con sé possibilmente accesso ai file, shell, browser, server MCP, email, calendario o altri strumenti interni. Se un membro del team può rivolgersi a questo agente, l’autorizzazione va ben oltre la scrittura di una risposta in chat.

La regola più importante è quindi: un agente deve poter lavorare solo nei channel il cui contenuto e i cui membri corrispondono al suo accesso agli strumenti. L’appartenenza al channel è la porta d’accesso centrale. Chi è membro può leggere e scrivere. Chi non è membro non dovrebbe poter vedere i channel privati né sottoscriverne gli event.

Le firme crittografiche non risolvono comunque ogni problema di audit. Buzz tiene un log di audit concatenato e visibilmente a prova di manipolazione. Un aggressore con accesso in scrittura al database potrebbe però ricalcolare la catena dopo una manipolazione. Il log è quindi tamper-evident, non tamper-resistant. Rende riconoscibili le modifiche finché la base di fiducia dello storage non è completamente compromessa.

Per le community ospitate da Block c’è un punto ulteriore: messaggi, messaggi diretti e media caricati non sono cifrati end-to-end. Block può accedere a questi contenuti per operatività, sicurezza, moderazione o obblighi legali. Inoltre il rispettivo fornitore di modello può ricevere prompt e contenuti del channel quando un agente usa un servizio cloud.

Il self-hosting cambia la sovranità dei dati, ma non automaticamente l’intero flusso di dati. Un relay proprio mantiene messaggi e file sulla propria infrastruttura. Se l’agente continua a usare un modello cloud, i dati necessari per l’incarico lasciano comunque il relay. Un funzionamento davvero locale richiede quindi sia un relay proprio sia modelli locali e tool locali. Sulle possibilità e i limiti di Buzz Shared Compute ho già scritto separatamente.

Come uso Buzz per ora

Per il mio primo test ho usato una community piccola e chiaramente delimitata. Nessuna credenziale di produzione, nessun dato cliente e nessun repository con segreti. Due agenti bastavano completamente: uno crea, uno verifica. A questo mi aggiungo io come persona, che stabilisce incarico, punto di approvazione e criterio di interruzione.

Il mio primo setup non era un’azienda autonoma con cento agenti, ma una review limitata:

• Un agente crea un piano tecnico a partire da un issue esistente.
• Un secondo agente cerca falle di sicurezza, assunzioni mancanti e complessità inutile.
• Entrambi devono citare fonti, file e domande aperte.
• Dopo al massimo due round di discussione il team aspetta l’approvazione umana.
• Solo dopo un agente può preparare modifiche in un worktree isolato.

Con questo ho potuto testare il vero punto di forza di Buzz senza dover ristrutturare subito tutta la mia operatività. Allo stesso tempo sono diventati visibili consumo di token, latenza, permessi e tracciabilità.

Per il lavoro da solo su un singolo compito di coding resto sull’interfaccia diretta dell’agente. È più veloce e più facile da controllare. Buzz diventa interessante non appena più persone, più agenti o più flussi di lavoro hanno bisogno dello stesso contesto. Piccoli team di sviluppo, agenzie, gruppi di ricerca e solopreneur esperti sono quindi il target naturale.

Per un’azienda più grande sarei più cauto. Prima della versione 1.0, senza una linea di supporto a lungo termine e con workflow ancora giovani, non farei di Buzz l’unico luogo per comunicazione critica o codice sorgente. Un progetto pilota può avere senso. Una sostituzione completa di Slack e GitHub sarebbe oggi una scommessa sulla velocità di sviluppo del progetto.

L’idea dietro Buzz è più grande del client attuale

La parte più affascinante di Buzz per me non è una singola funzione. Channel, forum, huddle, hosting Git e modelli locali esistono anche altrove. Nuova è l’assunzione coerente che gli agenti non siano più solo strumenti privati di singoli utenti. Diventano partecipanti visibili di un processo di lavoro condiviso.

Con questo si sposta la domanda. Non ci chiediamo più solo quale modello scriva il codice migliore. Dobbiamo decidere come persone e più agenti distribuiscono i compiti, condividono il contesto, si controllano a vicenda e rendono tracciabile la responsabilità. Proprio per questo oggi manca spesso l’infrastruttura sociale e tecnica.

Buzz non fornisce ancora una risposta definitiva. Il software è giovane, alcuni workflow sono inaffidabili, il contesto condiviso può diventare costoso e il self-hosting comporta una vera responsabilità operativa. Ciononostante il progetto coglie un problema reale. Se gli agenti si assumono sempre più lavoro, non basta aprire cinque chat singole una accanto all’altra. Serve un luogo comune dove il loro lavoro resti visibile, delimitato e verificabile.

Forse Buzz sostituirà Slack e GitHub prima o poi. Per oggi basta un’affermazione più piccola ma più importante: Buzz è una proposta convincente di come possa apparire uno spazio di lavoro quando non ci lavorano più solo persone. Shared Compute mi ha fatto notare il progetto. Lo spazio di lavoro condiviso è il motivo per cui continuerò a testare Buzz.

Il mio bilancio dopo il primo test

Buzz nel mio breve test ha colto esattamente il problema che ho al momento con gli agenti IA. I singoli modelli non sono più da tempo il collo di bottiglia. È difficile tenere più agenti, decisioni e risultati su una linea comune. Buzz rende visibile questo lavoro e dà a Codex, Claude Code e altri agenti un luogo dove possono reagire non solo a me, ma anche l’uno all’altro.

Mi hanno convinto il contesto condiviso, le identità degli agenti chiaramente separate e la possibilità di far attaccare un risultato direttamente da un secondo modello. Mi ha convinto meno l’overhead aggiuntivo. Per un singolo compito di coding la via diretta tramite Codex o Claude Code è ancora più veloce. Non appena sono coinvolti più agenti o persone, Buzz inizia a mostrare il suo punto di forza.

Il mio test è stato volutamente breve. Non ho verificato né un funzionamento di team duraturo né grandi repository, workflow complessi o picchi di carico prolungati. Il software è ancora troppo giovane e si muove troppo velocemente per questo. Oggi non farei di Buzz l’unico luogo per comunicazione critica o codice sorgente. Per un piccolo team, un’agenzia o un lab IA personale, però, è già più di una demo interessante. È uno strumento che continuerò a usare e che voglio integrare in modo mirato nella mia quotidianità di lavoro.

Alla prossima,
Joe

FAQ