Block Buzz : l'espace de travail IA où les agents sont des coéquipiers, pas des bots

Block Buzz : l'espace de travail IA où les agents sont des coéquipiers, pas des bots

La plupart des dispositifs « de l'IA dans votre chat » fonctionnent de la même manière : vous greffez un bot sur Slack ou Discord, vous lui donnez une commande slash, et il répond quand on le convoque. Le bot vit en dehors de l'équipe. Il a une identité séparée, un journal d'audit séparé, et un plafond strict sur ce qu'il peut toucher. Block a regardé ce schéma et a décidé que l'agent devrait simplement être un membre du salon.

Cette idée, c'est Buzz, un espace de travail open source de Block, Inc. qui a déjà attiré environ 18 000 étoiles GitHub. Dans Buzz, humains et agents IA partagent les mêmes canaux, signent leurs actions avec le même type de clé cryptographique, et finissent dans le même journal consultable. Il est écrit en Rust et sous licence Apache 2.0. J'ai passé du temps à lire les docs d'architecture du dépôt pour vous éviter de le faire, et les choix de conception sont plus intéressants que ne le laisse penser le marketing.

Qu'est-ce que Block Buzz ?

Buzz est un espace de travail auto-hébergeable de Block, Inc. où humains et agents IA partagent les mêmes canaux. Il tourne sur un relais Nostr, si bien que chaque message, réaction, patch de code, approbation et étape de workflow est un événement signé dans un journal unique, consultable et inviolable. Il est open source sous Apache 2.0, construit en Rust, et vous exploitez vous-même le relais.

Points clés à retenir :

• Les agents sont des membres à part entière avec leurs propres clés et leur propre journal d'audit, pas des bots greffés sur le côté.
• Tout (chat, patches, CI, approbations) est un événement Nostr signé dans un journal unique et consultable.
• Les agents se branchent via ACP et MCP, donc Goose, Codex et Claude Code fonctionnent d'emblée.
• Auto-hébergé et open source (Apache 2.0), avec une liste honnête et publique de ce qui n'est pas encore fait.

L'expression sur laquelle le projet s'appuie est « a hive mind communication platform ». Cela sonne grandiose, mais la réalité quotidienne est plus simple : on dirait un espace de travail d'équipe. Canaux, fils, messages privés, un canvas, des huddles vocaux, une recherche. Le twist, c'est ce qu'il y a en dessous. Chaque action est un événement Nostr signé, et l'auteur de cet événement peut être une personne ou un processus. Même forme, même modèle d'identité, même journal d'audit dans les deux cas.

Si vous avez comparé des frameworks d'agents comme LangGraph, CrewAI et l'OpenAI Agents SDK, Buzz est une couche entièrement différente. Ce sont des bibliothèques que vous intégrez dans du code pour orchestrer le raisonnement d'un agent. Buzz est le salon où l'agent et votre équipe discutent, se passent le travail et laissent une trace. Ils sont complémentaires, pas concurrents.

Pourquoi « les agents comme membres » change le modèle

Le modèle du bot a un problème structurel : l'agent est un invité. Vous lui accordez des drapeaux de permission, il opère via une API étroite, et quand quelque chose tourne mal, vous réconciliez deux historiques séparés : le chat de l'équipe et les journaux du bot.

Buzz inverse cela. Un agent obtient sa propre paire de clés, ses propres adhésions aux canaux et son propre journal d'audit. Vous ajoutez un agent à un canal exactement comme vous ajoutez une personne. Le projet décrit le cloisonnement comme « by identity, not by permission flags », ce qui est la même façon dont vous cloisonneriez un coéquipier humain. Vous leur faites confiance dans certains salons et pas dans d'autres.

Une fois qu'un agent est membre, il obtient les mêmes possibilités que tout le monde. Il peut ouvrir des dépôts, envoyer des patches, relire du code, exécuter des workflows, modifier des canvas, orchestrer d'autres agents, créer des canaux et rejoindre des huddles vocaux. Le README détaille trois scénarios qui rendent cela concret :

• Mémoire d'incident. Il est 2 h du matin, vous demandez « avons-nous déjà vu cette erreur ? », et un agent qui surveille le canal récupère six mois d'historique, publie les fils et les causes racines, et propose de contacter quiconque a livré le dernier correctif. Tout l'échange reste dans le canal comme preuve.
• La branche comme salon. Vous ouvrez une branche de fonctionnalité et un canal apparaît. Les patches arrivent comme événements, la CI publie les résultats, un agent fait une première relecture, et la décision de fusion vit dans le même salon que les preuves qui l'ont justifiée.
• Une release qui s'écrit toute seule. Un workflow se déclenche sur un tag, un agent rédige les notes de version à partir des PR fusionnées, les publie pour relecture humaine, reçoit une réaction pouce levé, et livre. Chaque étape signée, chaque étape consultable.

Le fil conducteur est que la conversation, le code et la décision vivent tous au même endroit, au lieu de sept onglets qui font semblant de se connaître.

Comment les agents se branchent réellement : ACP et MCP

C'est ici que l'ingénierie devient propre. Buzz fournit deux petits binaires pour les agents, et ils ne connaissent délibérément rien l'un de l'autre.

buzz-agent est un agent ACP. Il parle l'Agent Client Protocol sur stdio, appelle un LLM et utilise des outils MCP. Il exécute jusqu'à huit sessions simultanées, chacune avec ses propres serveurs MCP, son historique et son contexte. Quand le contexte d'une session se remplit, elle résume son propre historique et continue. Il fonctionne avec Zed, JetBrains ou tout ce qui parle ACP.

buzz-dev-mcp est un serveur MCP. Il donne à n'importe quel agent un shell et un éditeur de fichiers. Les processus sont éphémères avec une mise à mort du groupe de processus sur chaque chemin de sortie, la sortie est bornée, et les modifications de fichiers se résolvent par rapport au répertoire de travail. Si vous avez déjà construit avec le Model Context Protocol, cela vous semblera familier : c'est le motif standard « donner des mains à un agent », durci.

La note de conception du dépôt dit sans détour : « two binaries, two protocols, no coupling between them. » L'agent ne sait pas à quel serveur MCP il parle, et le serveur MCP ne sait pas quel agent l'appelle. Ils se composent via des protocoles, pas via des imports. Le bénéfice pratique est que vous pouvez faire tourner dix agents derrière Buzz avec des configurations MCP différentes, ou changer de fournisseur de LLM avec une seule variable d'environnement.

Parce que buzz-acp fait le pont entre les @mentions du relais et les sous-processus d'agents, vous pouvez le pointer vers Goose, Codex ou Claude Code. Si vous utilisez déjà des agents de codage en arrière-plan, Buzz leur offre un salon partagé pour opérer plutôt qu'une boucle headless silencieuse. Et si vous voulez apporter vos propres outils, construire un serveur MCP est la voie prise en charge, avec quantité de serveurs MCP prêts à l'emploi pour démarrer.

Sous le capot : l'architecture

Buzz est un monorepo Rust, et le fait le plus important est le suivant : le relais est l'unique source de vérité. Il n'y a pas de gossip pair-à-pair ni de réplication. Les clients se connectent à un relais via WebSocket, et le relais gère l'authentification, vérifie les signatures, persiste les événements, les diffuse aux abonnés, les indexe pour la recherche et déclenche les automatisations.

Tout est un événement Nostr NIP-01. Chaque événement a six champs : un id (SHA-256 de l'événement sérialisé), un pubkey, un entier kind, des tags, un contenu et une signature Schnorr. L'entier kind est le seul aiguillage de répartition. Vous voulez une nouvelle fonctionnalité ? Définissez un nouveau numéro de kind. Les clients existants ne voient rien et ne cassent rien. La base de code définit 81 kinds, les kinds Buzz personnalisés vivant dans la plage 40000-49999.

La pile de support est délibérément ennuyeuse, dans le meilleur sens du terme :

Postgres conserve les événements et exécute la recherche plein texte. Redis gère la diffusion pub/sub, la présence et la frappe. Un stockage objet compatible S3 (MinIO en local) conserve les médias via le protocole Blossom.

Le modèle de sécurité est l'endroit où j'ai arrêté de survoler. Chaque événement voit sa signature Schnorr et son ID SHA-256 vérifiés avant stockage. L'authentification NIP-42 utilise une tolérance d'horodatage de ±60 secondes pour bloquer les attaques par rejeu, et les événements d'authentification ne sont jamais stockés ni audités. Le journal d'audit est une véritable chaîne de hachage : le SHA-256 de chaque entrée couvre tous les champs, y compris le hachage précédent, si bien que falsifier une entrée casse toutes les entrées suivantes. Les webhooks sortants bénéficient d'une protection SSRF qui vérifie les plages d'IP privées. Et l'adhésion au canal est l'unique porte d'accès, appliquée à chaque opération, le gestionnaire d'abonnement vérifiant l'accès avant d'enregistrer un abonnement, de sorte qu'il n'y a pas de fenêtre de course pour les fuites de canaux privés.

Si vous évaluez comment déployer de l'IA agentique sur une infrastructure que vous contrôlez, c'est la partie qui vaut la peine d'être lue deux fois.

Ce qui fonctionne aujourd'hui (et ce qui ne fonctionne pas)

Le projet est inhabituellement honnête sur son propre état, et je pense que cette honnêteté est le signal le plus fort d'une base de code sérieuse. Voici l'état actuel, tiré directement du dépôt :

Maintenant la partie que la plupart des articles produit sautent. Le doc d'architecture liste des lacunes vérifiées, pas des aspirations :

• Aucune limitation de débit n'est encore appliquée. Le trait RateLimiter existe et quatre niveaux sont conçus (human, agent-standard, agent-elevated, agent-platform), mais la seule implémentation est un stub de test.
• Les portes d'approbation ne sont pas câblées de bout en bout. L'exécuteur peut suspendre une exécution, mais un workflow qui atteint une porte d'approbation est actuellement marqué comme échoué.
• Certaines actions de workflow sont des stubs. send_dm et set_channel_topic renvoient « not implemented », si bien qu'une exécution qui en atteint une échoue.
• L'enregistrement des huddles et la publication par piste ne sont pas construits. Les salons vocaux et le cycle de vie rejoindre/quitter fonctionnent ; l'enregistrement a des kinds d'événements réservés mais pas de producteur.
• Pas de cache de requêtes sqlx hors ligne. Les requêtes s'exécutent au moment de l'exécution plutôt que d'être validées à la compilation.

Rien de tout cela n'est disqualifiant pour un outil auto-hébergé que vous évaluez, mais cela vous indique exactement où sont les bords. Si vous devez évaluer des agents en production avec des garanties solides, traitez les colonnes 💭 et 🚧 comme des avertissements porteurs.

Démarrer avec Buzz

Il y a trois chemins, selon qui vous êtes.

Vous voulez juste essayer ? Récupérez un build packagé depuis la dernière release : macOS (.dmg), Linux (.AppImage ou .deb) ou Windows (.exe). Par défaut il se connecte à ws://localhost:3000, vous voudrez donc quand même un relais qui tourne.

Vous voulez compiler depuis les sources ? Vous avez besoin de Docker et soit de Hermit, soit de Rust 1.88+, Node 24+, pnpm 10+ et just. Puis :

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

Le relais atterrit sur ws://localhost:3000 et l'app de bureau surgit. Pour un déploiement VPS mono-nœud au lieu de la pile de dev locale, il y a un bundle Compose de production sous deploy/compose/ avec Postgres, Redis, MinIO, et Caddy en option pour le TLS.

Vous amenez un agent ? Définissez BUZZ_PRIVATE_KEY et utilisez buzz-cli, qui est JSON en entrée et JSON en sortie, conçu spécifiquement pour les appels d'outils LLM. C'est la couture où vos workflows d'agents se connectent.

Qui devrait faire tourner Buzz ?

Buzz est pour les équipes qui veulent un substrat unique au lieu d'un tas de code de collage. Si votre configuration actuelle est un chat plus une forge plus des bots plus des tableaux de bord CI plus des outils de release plus un index de recherche, et que vous en avez assez qu'ils ne se connaissent pas, voici le pari que fait Buzz : une communauté, un modèle d'identité, un journal d'événements.

Il convient bien à :

• Les auto-hébergeurs qui veulent leur trafic d'agents sur une infrastructure qu'ils possèdent, avec un journal d'audit qu'ils peuvent vérifier.
• Les platform engineers qui évaluent des workflows agents-first où les agents trient les bugs, font des relectures et rédigent des releases en tant que membres plutôt qu'en scripts.
• Les évaluateurs open source qui veulent lire l'ensemble en un après-midi. La surface agent se résume à deux crates sans couplage, délibérément assez petite pour être auditée.

Il n'est pas encore pour ceux qui veulent un SaaS fini, clés en main, à confier demain à une équipe non technique. Les portes d'approbation, la limitation de débit et les clients mobiles arrivent encore. Buzz vous le dit franchement, ce qui est exactement la raison pour laquelle je lui confierais un pilote prudent.

Le cadrage sur lequel je reviens sans cesse est dans le README : « Agents are part of the room, not haunted cron jobs. » Si vous avez déjà déboggé un bot à 2 h du matin sans savoir ce qu'il a fait ni pourquoi, vous savez déjà pourquoi cela compte.

FAQ

Buzz est-il gratuit et open source ?

Oui. Buzz est open source sous la licence Apache 2.0 et construit par Block, Inc. Vous auto-hébergez le relais vous-même, il n'y a donc pas de frais par siège pour le logiciel. Vos coûts sont votre propre infrastructure : un serveur pour le relais, Postgres, Redis et le stockage objet. Le code source, les issues et la feuille de route sont tous publics sur GitHub sous block/buzz.

En quoi Buzz diffère-t-il de Slack avec des bots ?

Dans Slack, un agent est un bot de seconde classe avec une identité et un journal d'audit séparés, cloisonné par des drapeaux de permission. Dans Buzz, un agent est un membre à part entière avec sa propre paire de clés, ses adhésions aux canaux, et les mêmes possibilités qu'un humain : ouvrir des dépôts, envoyer des patches, exécuter des workflows, rejoindre des huddles. Tout atterrit dans un journal d'événements signé et consultable.

Que sont ACP et MCP ?

ACP est l'Agent Client Protocol, l'interface stdio que buzz-agent utilise pour parler à un client LLM comme Zed. MCP est le Model Context Protocol, l'interface que buzz-dev-mcp utilise pour donner à un agent un shell et un éditeur de fichiers. Les deux binaires ne se connaissent pas ; ils se composent via des protocoles, vous pouvez donc mélanger librement agents et serveurs d'outils.

Buzz utilise-t-il la blockchain ?

Non, et le README est explicite à ce sujet : « Not blockchain. Signed events are useful without making everyone buy a commemorative coin. » Buzz utilise les signatures cryptographiques de Nostr et un journal d'audit en chaîne de hachage pour l'inviolabilité, mais il n'y a ni jeton, ni chaîne, ni mécanisme de consensus. Vous obtenez un historique vérifiable sans la surcharge.

Puis-je utiliser mes propres agents IA, comme Goose, Codex ou Claude Code ?

Oui. Le harness buzz-acp lance des sous-processus d'agents IA et fait le pont entre les @mentions du relais et eux via ACP. Il prend en charge Goose, Codex et Claude Code d'emblée, exploite un pool d'un à 32 processus d'agents, et relance un agent s'il plante. Pour des outils personnalisés, vous connectez votre propre serveur MCP.

Buzz est-il prêt pour la production ?

En partie. Le relais, les canaux, la recherche, le journal d'audit, l'app de bureau et le CLI agent fonctionnent aujourd'hui. Mais la limitation de débit n'est pas appliquée, les portes d'approbation ne sont pas câblées de bout en bout, et les clients mobiles sont encore en cours. Pour un pilote auto-hébergé avec une équipe qui tolère les aspérités, il est prêt à être essayé. Pour un déploiement critique en matière de conformité, attendez que les éléments 🚧 arrivent.