Buzz Jack Dorsey: workspace humains et agents IA (buzz.xyz)

Buzz Jack Dorsey en une phrase

Buzz (buzz.xyz) est un workspace open source, annoncé le 21 juillet 2026 par Block, où humains et agents IA partagent les mêmes canaux, threads et permissions, plutôt que de coller le résultat d'un agent dans Slack.

Si tu cherches « Buzz Jack Dorsey », tu tombes surtout sur des annonces. Ici on détaille qui l'a construit, pour quelle raison d'architecture, ce qu'on en a tiré en prise en main, et ce que tu dois figer en PME avant d'y coller des agents en production.

Qui a créé Buzz ?

Buzz est un produit de Block (ex-Square), la société de Jack Dorsey, aussi connue pour Cash App et l'investissement dans l'open source IA (dont goose). L'annonce officielle est sur le blog Block: Introducing Buzz: where humans and agents work together.

Jack Dorsey porte le lancement dans la presse (TechCrunch et d'autres le présentent comme un concurrent potentiel de Slack / collab + agents). Ce n'est pas un side-project anonyme: c'est une brique stratégique Block sur l'infra d'agents.

Côté produit, Bradley Axen (Head of AI Capabilities chez Block) résume le pari: chaque entreprise aura besoin d'un lieu où humains et agents travaillent ensemble; la question est de savoir si ce lieu est propriétaire ou ouvert. Block a construit Buzz pour le second camp.

Licence annoncée: Apache-2.0, code sur github.com/block/buzz. Hébergement géré via buzz.xyz ou self-host. L'open source n'est pas un détail marketing: c'est l'argument contre le lock-in des plateformes d'agents propriétaires.

Pourquoi Buzz a été créé

Block dit avoir open-sourcé des outils IA pendant deux ans, puis constaté un pattern: le travail productif n'arrive pas quand quelqu'un « demande de l'aide à l'IA » dans un coin. Il arrive quand humains et agents sont dans la même pièce, sur la même tâche, avec le même contexte. Aucune plateforme n'était conçue pour ça, donc ils en ont bâti une.

Le second « pourquoi » est structurel. Beaucoup d'entreprises construisent leur stack agents dans des plateformes propriétaires: règles d'accès, modèles autorisés, formats de conversation imposés par le vendeur. Ça fragmente l'organisation et crée de la dépendance. Buzz veut un standard ouvert de collab humains/agents, comme le code qu'on versionne soi-même.

Le troisième « pourquoi » est l'identité. Buzz s'appuie sur Nostr: chaque participant, humain ou agent, détient une paire de clés crypto qui lui appartient, pas un compte plateforme. L'identité de l'agent n'est pas une API key vendeur. Elle est portable et vérifiable. Sans identité propre, un agent reste un plugin collé à un SaaS.

En pratique: arrêter le copier-coller permanent entre terminal d'agent (Claude Code, Codex, goose…) et chat d'équipe (Slack), et réunir conversation + code + agents sous un relais que tu peux contrôler.

Ce que fait Buzz (fonctionnellement)

L'interface est familière: canaux, threads, DMs, voix, médias, recherche. S'y ajoutent des dépôts / Git encore early, et des workflows automatisés. Les agents ne sont pas des assistants one-shot dans un panneau latéral: ils ont des permissions, peuvent poster, revoir du code, lancer des automatisations approuvées, et s'empiler à plusieurs avec plusieurs humains sur le même fil.

Buzz se dit model-agnostic et agent-agnostic: Claude Code, Codex, goose, modèle local, ou harness maison. Le workspace ne prescrit pas le moteur. Il prescrit le lieu et les règles d'accès aux outils (CRM, repo, fichiers) que l'équipe configure.

Ce n'est pas magique: c'est une surface de collab. La qualité dépend toujours du harness, du modèle, des permissions, et de ta policy d'approbation.

Notre prise en main (kengdev)

On a ouvert un workspace Buzz et branché un agent dans un canal type Welcome. Premier réflexe: une question banale pour voir si l'agent se comporte comme un collègue de fil, pas comme un chat latéral. Demande: « donne-moi des exemples de ce que tu peux faire ».

La réponse arrive dans le thread, structurée (dev, recherche, contenu, design, automatisation), avec des phrases d'amorçage et une invitation à préciser le gain de temps. Pas de panneau magique hors contexte: le travail se voit où l'équipe lit déjà. C'est le premier « ah »: délégation par mention, comme un humain, avec un fil que n'importe qui peut relire après.

En creusant, on retrouve le même ressenti que sur d'autres prises en main sérieuses du produit: Buzz n'est pas « un autre chatbot dans Slack ». C'est plutôt un mix familier (canaux / threads type messagerie d'équipe) + couche d'agents first-class (identité, historique, délégation) + harness au choix (Claude Code, Codex, goose, modèles locaux). L'agent peut s'appuyer sur un harness, choisir un modèle, et, dans les scénarios plus avancés, déléguer et travailler en parallèle (worktrees git inclus).

Ce qu'on aime vraiment en usage: tagger l'agent et le voir répondre dans le fil avec des mises à jour de statut quand il avance (compile, commit, déploie) est naturel. Le fil reste un brief pour le reste de l'équipe. On n'a plus à reconstituer un transcript terminal pour expliquer « ce que l'agent a fait ». Le compute partagé (un relais / une machine plus costaude mise à disposition d'une communauté) et l'ancrage Nostr (identité portable, piste Lightning pour micropaiements de compute à terme) sont aussi ce qui sépare Buzz d'un simple agent manager collé à un SaaS fermé.

Ce qui freine encore, et c'est net dès les premières sessions: on ne voit pas le terminal de l'agent. Il y a une vue d'activité, mais si tu es habitué à regarder une session Claude Code défiler, l'UI Buzz reste abstraite. On a aussi eu l'impression, sans mesure stricte, que les allers-retours sont plus lents qu'une session locale dans le harness: pour les one-shot, on retombe instinctivement sur le terminal. Autre limite: on aimerait plus de contrôle sur la session backend (réutiliser le même id de session pour le même agent, rejouer, inspecter). Sans ça, l'intégration « full time » dans le flux d'une équipe reste hésitante.

Verdict interne, après cette prise en main: on aime le modèle et on peut imaginer travailler en équipe comme ça. Pour des tâches moyennes (cadrage, explications, petits lots, status partagés), c'est déjà pertinent. Pour les gros chantiers complexes, ce n'est pas encore le socle unique. Le différenciateur long terme (compute partagé + identité ouverte + fil commun) est réel; le produit reste early. On garde Claude Code / Codex pour le deep coding, et on utilise Buzz pour la collab visible multi-humains multi-agents, avec une policy d'approbation écrite avant d'élargir le périmètre.

Ce que les briefs FR ne disent pas assez (PME)

Beaucoup de contenus FR se contentent de: « Jack Dorsey sort Buzz, open source, agents membres, Nostr ». C'est vrai, et insuffisant pour décider.

Ce qu'il manque souvent: le contrat d'approbation (HITL), la cartographie des secrets et des écritures, le split terminal vs workspace, et la différence entre un chat multi-agents et un agent ops packagé sur un process métier (devis, support, CRM).

Si tu pilotes une PME, pose trois questions avant le FOMO: (1) Où tourne le relais et qui lit les logs ? (2) Quelles actions l'agent peut faire sans clic humain ? (3) Que se passe-t-il si Buzz ou le harness plante en plein sprint ? Sans réponses écrites, tu n'as pas de migration. Tu as une démo sociale.

Garde-fous avant d'y coller des agents

Une page de policy suffit pour démarrer: actions auto (format, lint, résumé), actions qui demandent un clic (push main, secrets, migration), actions interdites (prod live, paiement, suppression large). Versionne-la comme du code.

Cartographie les flux: clés API, outils branchés, données client, rétention des threads. Open source et self-host ne remplacent pas une lecture RGPD et un least-privilege réel.

Sépare les usages: deep coding dans un harness terminal; collab visible (revue, status, handoff) dans un workspace type Buzz; ops métier récurrents avec allowlist d'écritures. Chez kengdev, le pattern machine propose → humain valide reste non négociable, quelle que soit l'UI.

Mesure le temps gagné et le taux d'escalade, pas le nombre de messages de l'agent. Plus de commits ne veut pas dire plus de valeur.

Buzz vs Claude Code vs Hermès Ops

Claude Code / Codex: harness d'exécution, fort sur le terminal et le patch. Buzz: surface de collab multi-humains multi-agents, fort sur le contexte partagé et l'identité ouverte. Hermès Ops (pack kengdev): agent ops branché messagerie + outils métier, écritures critiques derrière confirmation humaine, périmètre process plutôt que chat généraliste.

Tu n'as pas à choisir un seul outil pour toujours. Tu choisis le périmètre. Buzz pousse la « salle commune ». Ça ne remplace ni un runbook de production ni une policy d'approbation.

Si vous voulez cadrer un premier agent sur un process réel (support, devis, ops), avec ou sans Buzz dans la boucle, on peut le faire en 20-40 minutes.