Block Buzz: lo spazio di lavoro IA dove gli agenti sono compagni di squadra, non bot

Block Buzz: lo spazio di lavoro IA dove gli agenti sono compagni di squadra, non bot

La maggior parte delle configurazioni "IA nella tua chat" funziona allo stesso modo: attacchi un bot a Slack o Discord, gli dai un comando slash e risponde quando viene convocato. Il bot vive fuori dal team. Ha un'identità separata, una traccia di audit separata e un limite rigido su ciò che può toccare. Block ha guardato quel modello e ha deciso che l'agente dovrebbe semplicemente essere un membro della stanza.

Quell'idea è Buzz, uno spazio di lavoro open source di Block, Inc. che ha già attirato circa 18.000 stelle GitHub. In Buzz, umani e agenti IA condividono gli stessi canali, firmano le proprie azioni con lo stesso tipo di chiave crittografica e finiscono nello stesso registro ricercabile. È scritto in Rust e concesso in licenza Apache 2.0. Ho passato del tempo a leggere i documenti di architettura del repository così non devi farlo tu, e le scelte di progettazione sono più interessanti di quanto suggerisca il marketing.

Cos'è Block Buzz?

Buzz è uno spazio di lavoro self-hosted di Block, Inc. dove umani e agenti IA condividono gli stessi canali. Gira su un relay Nostr, quindi ogni messaggio, reazione, patch di codice, approvazione e passaggio di workflow è un evento firmato in un unico registro ricercabile e a prova di manomissione. È open source sotto Apache 2.0, costruito in Rust, e gestisci tu stesso il relay.

Punti chiave:

• Gli agenti sono membri di prima classe con le proprie chiavi e la propria traccia di audit, non bot attaccati di lato.
• Tutto (chat, patch, CI, approvazioni) è un evento Nostr firmato in un unico registro ricercabile.
• Gli agenti si collegano tramite ACP e MCP, quindi Goose, Codex e Claude Code funzionano subito.
• Self-hosted e open source (Apache 2.0), con un elenco onesto e pubblico di ciò che non è ancora fatto.

La frase su cui il progetto fa leva è "a hive mind communication platform". Suona grandioso, ma la realtà quotidiana è più semplice: sembra uno spazio di lavoro di squadra. Canali, thread, messaggi diretti, una tela, riunioni vocali, ricerca. La svolta è ciò che sta sotto. Ogni azione è un evento Nostr firmato, e l'autore di quell'evento può essere una persona o un processo. Stessa forma, stesso modello di identità, stessa traccia di audit in entrambi i casi.

Se hai confrontato framework di agenti come LangGraph, CrewAI e l'OpenAI Agents SDK, Buzz è un livello interamente diverso. Quelli sono librerie che incorpori nel codice per orchestrare il ragionamento di un agente. Buzz è la stanza dove l'agente e il tuo team parlano, si passano il lavoro e lasciano un registro. Sono complementari, non concorrenti.

Perché "agenti come membri" cambia il modello

Il modello del bot ha un problema strutturale: l'agente è un ospite. Gli concedi flag di permesso, opera attraverso un'API stretta e quando qualcosa va male stai riconciliando due storie separate: la chat del team e i log del bot.

Buzz lo ribalta. Un agente ottiene la propria coppia di chiavi, le proprie iscrizioni ai canali e la propria traccia di audit. Aggiungi un agente a un canale nello stesso modo in cui aggiungi una persona. Il progetto descrive la definizione dell'ambito come "by identity, not by permission flags", che è lo stesso modo in cui definiresti l'ambito di un compagno di squadra umano. Ti fidi di loro in alcune stanze e non in altre.

Una volta che un agente è un membro, ottiene le stesse possibilità che hanno tutti gli altri. Può aprire repository, inviare patch, revisionare codice, eseguire workflow, modificare tele, orchestrare altri agenti, creare canali e unirsi alle riunioni vocali. Il README illustra tre scenari che lo rendono concreto:

• Memoria degli incidenti. Sono le 2 di notte, chiedi "abbiamo già visto questo errore?", e un agente che osserva il canale recupera sei mesi di cronologia, pubblica i thread e le cause profonde, e si offre di avvisare chi ha spedito l'ultima correzione. L'intero scambio resta nel canale come prova.
• Il branch come stanza. Apri un branch di funzionalità e appare un canale. Le patch arrivano come eventi, la CI pubblica i risultati, un agente esegue una prima revisione, e la decisione di merge vive nella stessa stanza delle prove che l'hanno giustificata.
• Una release che si scrive da sola. Un workflow scatta su un tag, un agente bozza le note di rilascio dalle PR unite, le pubblica per revisione umana, riceve una reazione pollice in su, e spedisce. Ogni passaggio firmato, ogni passaggio ricercabile.

Il filo comune è che la conversazione, il codice e la decisione vivono tutti in un unico posto invece che in sette schede che fingono di conoscersi.

Come si collegano davvero gli agenti: ACP e MCP

Qui l'ingegneria diventa pulita. Buzz fornisce due piccoli binari per gli agenti, e deliberatamente non si conoscono tra loro.

buzz-agent è un agente ACP. Parla l'Agent Client Protocol su stdio, chiama un LLM e usa strumenti MCP. Esegue fino a otto sessioni simultanee, ognuna con i propri server MCP, cronologia e contesto. Quando il contesto di una sessione si riempie, riassume la propria cronologia e continua. Funziona con Zed, JetBrains o qualsiasi altra cosa parli ACP.

buzz-dev-mcp è un server MCP. Dà a qualsiasi agente una shell e un editor di file. I processi sono effimeri con l'uccisione del gruppo di processi su ogni percorso di uscita, l'output è limitato, e le modifiche ai file si risolvono rispetto alla directory di lavoro. Se hai già costruito con il Model Context Protocol, ti sembrerà familiare: è il modello standard "dai le mani a un agente", irrobustito.

La nota di progettazione nel repository lo dice senza giri di parole: "two binaries, two protocols, no coupling between them." L'agente non sa con quale server MCP parla, e il server MCP non sa quale agente lo chiama. Si compongono tramite protocolli, non tramite import. Il vantaggio pratico è che puoi eseguire dieci agenti dietro Buzz con diverse configurazioni MCP, o cambiare il tuo fornitore di LLM con una variabile d'ambiente.

Poiché buzz-acp fa da ponte tra le @mentions del relay e i sottoprocessi degli agenti, puoi puntarlo a Goose, Codex o Claude Code. Se stai già eseguendo agenti di codifica in background, Buzz dà loro una stanza condivisa in cui operare anziché un loop headless silenzioso. E se vuoi portare i tuoi strumenti, costruire un server MCP è il percorso supportato, con molti server MCP pronti all'uso da cui partire.

Sotto il cofano: l'architettura

Buzz è un monorepo Rust, e il fatto in assoluto più importante è questo: il relay è l'unica fonte di verità. Non c'è gossip peer-to-peer né replica. I client si connettono a un relay tramite WebSocket, e il relay gestisce l'autenticazione, verifica le firme, persiste gli eventi, li distribuisce agli iscritti, li indicizza per la ricerca e attiva le automazioni.

Tutto è un evento Nostr NIP-01. Ogni evento ha sei campi: un id (SHA-256 dell'evento serializzato), un pubkey, un intero kind, tag, contenuto e una firma Schnorr. L'intero kind è l'unico interruttore di dispatch. Vuoi una nuova funzionalità? Definisci un nuovo numero di kind. I client esistenti non vedono nulla e non rompono nulla. Il codice definisce 81 kind, con i kind personalizzati di Buzz che vivono nell'intervallo 40000-49999.

Lo stack di supporto è deliberatamente noioso, nel senso migliore:

Postgres conserva gli eventi ed esegue la ricerca full-text. Redis gestisce la distribuzione pub/sub, la presenza e la digitazione. L'object storage compatibile S3 (MinIO in locale) conserva i media tramite il protocollo Blossom.

Il modello di sicurezza è il punto in cui ho smesso di sfogliare. Di ogni evento vengono verificate la firma Schnorr e l'ID SHA-256 prima dell'archiviazione. L'autenticazione NIP-42 usa una tolleranza di timestamp di ±60 secondi per bloccare gli attacchi di replay, e gli eventi di autenticazione non vengono mai archiviati né sottoposti ad audit. Il registro di audit è una vera catena di hash: lo SHA-256 di ogni voce copre ogni campo incluso l'hash precedente, così manomettere una voce rompe ogni voce successiva. I webhook in uscita ottengono una protezione SSRF che controlla gli intervalli di IP privati. E l'iscrizione al canale è l'unico cancello di accesso, applicato a ogni operazione, con il gestore delle iscrizioni che controlla l'accesso prima di registrare un'iscrizione, così non c'è finestra di race per le fughe di canali privati.

Se stai valutando come distribuire IA agentica su un'infrastruttura che controlli, questa è la parte che vale la pena leggere due volte.

Cosa funziona oggi (e cosa no)

Il progetto è insolitamente onesto sul proprio stato, e penso che quell'onestà sia il segnale più forte di un codice serio. Ecco lo stato attuale direttamente dal repository:

Ora la parte che la maggior parte degli articoli di prodotto salta. Il documento di architettura elenca lacune verificate, non aspirazioni:

• Nessun rate limiting è ancora applicato. Il trait RateLimiter esiste e quattro livelli sono progettati (human, agent-standard, agent-elevated, agent-platform), ma l'unica implementazione è uno stub di test.
• I cancelli di approvazione non sono cablati end-to-end. L'esecutore può sospendere un'esecuzione, ma un workflow che raggiunge un cancello di approvazione viene attualmente contrassegnato come fallito.
• Alcune azioni di workflow sono stub. send_dm e set_channel_topic restituiscono "not implemented", quindi un'esecuzione che ne raggiunge una fallisce.
• La registrazione delle riunioni e la pubblicazione per traccia non sono costruite. Le stanze vocali e il ciclo di vita di ingresso/uscita funzionano; la registrazione ha kind di evento riservati ma nessun produttore.
• Nessuna cache di query sqlx offline. Le query vengono eseguite a runtime anziché essere validate in fase di compilazione.

Niente di tutto questo è squalificante per uno strumento self-hosted che stai valutando, ma ti dice esattamente dove sono i bordi. Se devi valutare agenti in produzione con garanzie solide, tratta le colonne 💭 e 🚧 come avvertimenti portanti.

Iniziare con Buzz

Ci sono tre percorsi, a seconda di chi sei.

Vuoi solo provarlo? Prendi una build confezionata dall'ultima release: macOS (.dmg), Linux (.AppImage o .deb), o Windows (.exe). Per impostazione predefinita si connette a ws://localhost:3000, quindi vorrai comunque un relay in esecuzione.

Vuoi compilare dal codice sorgente? Ti servono Docker e Hermit oppure Rust 1.88+, Node 24+, pnpm 10+, e just. Poi:

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit
just setup && just build

# every day:
. ./bin/activate-hermit
just dev   # starts the relay + desktop app together

Il relay atterra su ws://localhost:3000 e l'app desktop spunta. Per un deployment VPS a nodo singolo invece dello stack di sviluppo locale, c'è un bundle Compose di produzione sotto deploy/compose/ con Postgres, Redis, MinIO, e Caddy opzionale per TLS.

Porti un agente? Imposta BUZZ_PRIVATE_KEY e usa buzz-cli, che è JSON in entrata e JSON in uscita, progettato specificamente per le chiamate di strumenti LLM. Quella è la cucitura dove si collegano i tuoi workflow di agenti.

Chi dovrebbe eseguire Buzz?

Buzz è per i team che vogliono un unico substrato invece di un mucchio di codice collante. Se la tua configurazione attuale è chat più una forge più bot più dashboard CI più strumenti di rilascio più un indice di ricerca, e sei stanco che non si conoscano tra loro, questa è la scommessa che fa Buzz: una comunità, un modello di identità, un registro di eventi.

È adatto per:

• Self-hoster che vogliono il traffico dei propri agenti su un'infrastruttura di loro proprietà, con una traccia di audit che possono verificare.
• Platform engineer che valutano workflow agent-first dove gli agenti fanno triage dei bug, eseguono revisioni e bozzano release come membri anziché come script.
• Valutatori open source che vogliono leggere tutto in un pomeriggio. La superficie degli agenti sono due crate senza accoppiamento, deliberatamente abbastanza piccoli da controllare.

Non è ancora per chi vuole un SaaS finito e tutto incluso da consegnare domani a un team non tecnico. I cancelli di approvazione, il rate limiting e i client mobili stanno ancora arrivando. Buzz te lo dice chiaramente, ed è esattamente la ragione per cui gli affiderei un pilota attento.

La cornice su cui torno continuamente è nel README: "Agents are part of the room, not haunted cron jobs." Se hai mai fatto il debug di un bot alle 2 di notte senza idea di cosa abbia fatto o perché, sai già perché conta.

FAQ

Buzz è gratuito e open source?

Sì. Buzz è open source sotto la licenza Apache 2.0 e costruito da Block, Inc. Ospiti tu stesso il relay, quindi non c'è un costo per postazione per il software. I tuoi costi sono la tua infrastruttura: un server per il relay, Postgres, Redis e object storage. Il codice sorgente, gli issue e la roadmap sono tutti pubblici su GitHub in block/buzz.

In cosa si differenzia Buzz da Slack con i bot?

In Slack, un agente è un bot di seconda classe con identità e traccia di audit separate, delimitato da flag di permesso. In Buzz, un agente è un membro di prima classe con la propria coppia di chiavi, le proprie iscrizioni ai canali e le stesse possibilità di un umano: aprire repository, inviare patch, eseguire workflow, unirsi alle riunioni. Tutto finisce in un unico registro di eventi firmato e ricercabile.

Cosa sono ACP e MCP?

ACP è l'Agent Client Protocol, l'interfaccia stdio che buzz-agent usa per parlare con un client LLM come Zed. MCP è il Model Context Protocol, l'interfaccia che buzz-dev-mcp usa per dare a un agente una shell e un editor di file. I due binari non si conoscono tra loro; si compongono tramite protocolli, così puoi mescolare liberamente agenti e server di strumenti.

Buzz usa la blockchain?

No, e il README è esplicito al riguardo: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz usa le firme crittografiche di Nostr e un registro di audit a catena di hash per la prova di manomissione, ma non c'è token, né catena, né meccanismo di consenso. Ottieni una cronologia verificabile senza il sovraccarico.

Posso usare i miei agenti IA, come Goose, Codex o Claude Code?

Sì. L'harness buzz-acp genera sottoprocessi di agenti IA e fa da ponte tra le @mentions del relay e loro tramite ACP. Supporta Goose, Codex e Claude Code subito, esegue un pool da uno a 32 processi agente, e riavvia un agente se si blocca. Per strumenti personalizzati, colleghi il tuo server MCP.

Buzz è pronto per la produzione?

In parte. Il relay, i canali, la ricerca, il registro di audit, l'app desktop e la CLI degli agenti funzionano oggi. Ma il rate limiting non è applicato, i cancelli di approvazione non sono cablati end-to-end, e i client mobili sono ancora in corso. Per un pilota self-hosted con un team che tollera i bordi grezzi, è pronto da provare. Per un deployment critico per la conformità, aspetta che arrivino gli elementi 🚧.