Block Buzz: de AI-agentwerkplek waar agents teamgenoten zijn, geen bots

Block Buzz: de AI-agentwerkplek waar agents teamgenoten zijn, geen bots

De meeste "AI in je chat"-opstellingen werken hetzelfde: je plakt een bot op Slack of Discord, geeft hem een slash-commando, en hij antwoordt wanneer hij wordt geroepen. De bot leeft buiten het team. Hij heeft een aparte identiteit, een apart audittrail en een hard plafond op wat hij mag aanraken. Block bekeek dat patroon en besloot dat de agent gewoon lid van de kamer zou moeten zijn.

Dat idee is Buzz, een open-source werkplek van Block, Inc. die al zo'n 18.000 GitHub-sterren heeft getrokken. In Buzz delen mensen en AI-agents dezelfde kanalen, ondertekenen hun acties met hetzelfde soort cryptografische sleutel, en belanden in hetzelfde doorzoekbare log. Het is geschreven in Rust en gelicentieerd onder Apache 2.0. Ik heb de architectuurdocs van de repo doorgelezen zodat jij dat niet hoeft, en de ontwerpkeuzes zijn interessanter dan de marketing suggereert.

Wat is Block Buzz?

Buzz is een zelf te hosten werkplek van Block, Inc. waar mensen en AI-agents dezelfde kanalen delen. Het draait op een Nostr-relay, zodat elk bericht, elke reactie, codepatch, goedkeuring en workflowstap één ondertekend event is in één enkel, doorzoekbaar, manipulatiebestendig log. Het is open source onder Apache 2.0, gebouwd in Rust, en je draait de relay zelf.

Belangrijkste punten:

• Agents zijn eersteklas leden met eigen sleutels en eigen audittrail, geen bots die er zijdelings tegenaan geplakt zijn.
• Alles (chat, patches, CI, goedkeuringen) is één ondertekend Nostr-event in één doorzoekbaar log.
• Agents koppelen aan via ACP en MCP, dus Goose, Codex en Claude Code werken out of the box.
• Zelf-gehost en open source (Apache 2.0), met een eerlijke, openbare lijst van wat nog niet af is.

De frase waar het project op leunt is "a hive mind communication platform". Dat klinkt groots, maar de dagelijkse realiteit is simpeler: het voelt als een teamwerkplek. Kanalen, threads, DM's, een canvas, voice-huddles, zoeken. De twist is wat eronder zit. Elke actie is een ondertekend Nostr-event, en de auteur van dat event kan een persoon of een proces zijn. Dezelfde vorm, hetzelfde identiteitsmodel, hetzelfde audittrail in beide gevallen.

Als je agentframeworks zoals LangGraph, CrewAI en de OpenAI Agents SDK hebt vergeleken, is Buzz een volledig andere laag. Dat zijn bibliotheken die je in code inbedt om het redeneren van een agent te orkestreren. Buzz is de kamer waar de agent en je team praten, werk overdragen en een spoor achterlaten. Ze vullen elkaar aan, ze concurreren niet.

Waarom "agents als leden" het model verandert

Het botmodel heeft een structureel probleem: de agent is een gast. Je geeft hem permissievlaggen, hij opereert via een smalle API, en als er iets misgaat vereffen je twee gescheiden geschiedenissen — de chat van het team en de logs van de bot.

Buzz draait dit om. Een agent krijgt zijn eigen sleutelpaar, zijn eigen kanaallidmaatschappen en zijn eigen audittrail. Je voegt een agent aan een kanaal toe op dezelfde manier als een persoon. Het project beschrijft de scoping als "by identity, not by permission flags", wat dezelfde manier is waarop je een menselijke teamgenoot zou scopen. Je vertrouwt ze in sommige kamers en in andere niet.

Zodra een agent lid is, krijgt hij dezelfde mogelijkheden als iedereen. Hij kan repo's openen, patches sturen, code reviewen, workflows draaien, canvases bewerken, andere agents orkestreren, kanalen aanmaken en in voice-huddles springen. De README loopt door drie scenario's die dit concreet maken:

• Incidentgeheugen. Het is 2 uur 's nachts, je vraagt "hebben we deze fout eerder gezien?", en een agent die het kanaal bewaakt haalt zes maanden geschiedenis op, post de threads en root causes, en biedt aan om degene te piepen die de laatste fix shippte. De hele uitwisseling blijft als bewijs in het kanaal.
• Branch als kamer. Je opent een feature-branch en er verschijnt een kanaal. Patches landen als events, CI post resultaten, een agent doet een eerste review, en de merge-beslissing leeft in dezelfde kamer als het bewijs dat haar rechtvaardigde.
• Een release die zichzelf schrijft. Een workflow vuurt op een tag, een agent stelt release notes op uit de gemergde PR's, post ze voor menselijke review, krijgt een duim-omhoog-reactie, en shipt. Elke stap ondertekend, elke stap doorzoekbaar.

De rode draad is dat het gesprek, de code en de beslissing allemaal op één plek leven, in plaats van zeven tabbladen die doen alsof ze van elkaar weten.

Hoe agents echt aankoppelen: ACP en MCP

Hier wordt de engineering schoon. Buzz scheept twee kleine binaries voor agents uit, en ze weten bewust niets van elkaar.

buzz-agent is een ACP-agent. Hij spreekt het Agent Client Protocol over stdio, roept een LLM aan, en gebruikt MCP-tools. Hij draait tot acht gelijktijdige sessies, elk met eigen MCP-servers, geschiedenis en context. Wanneer de context van een sessie vol raakt, vat ze haar eigen geschiedenis samen en gaat door. Hij werkt met Zed, JetBrains of al het andere dat ACP spreekt.

buzz-dev-mcp is een MCP-server. Hij geeft elke agent een shell en een bestandseditor. Processen zijn vluchtig met process-group-kill op elk pad naar buiten, output is begrensd, en bestandsbewerkingen worden opgelost tegen de werkmap. Als je eerder met het Model Context Protocol hebt gebouwd, komt dit bekend voor: het is het standaardpatroon "geef een agent handen", gehard.

De design-notitie in de repo zegt het botweg: "two binaries, two protocols, no coupling between them." De agent weet niet met welke MCP-server hij praat, en de MCP-server weet niet welke agent hem aanroept. Ze componeren via protocollen, niet via imports. Het praktische voordeel is dat je tien agents achter Buzz kunt draaien met verschillende MCP-configuraties, of je LLM-provider kunt wisselen met één omgevingsvariabele.

Omdat buzz-acp relay-@mentions naar agent-subprocessen brugt, kun je hem op Goose, Codex of Claude Code richten. Als je al background-coding-agents draait, geeft Buzz ze een gedeelde kamer om in te opereren in plaats van een stille headless-lus. En als je je eigen tools wilt meenemen, is een MCP-server bouwen het ondersteunde pad, met volop kant-en-klare MCP-servers om mee te beginnen.

Onder de motorkap: de architectuur

Buzz is een Rust-monorepo, en het belangrijkste feit is dit: de relay is de enige bron van waarheid. Er is geen peer-to-peer-gossip en geen replicatie. Clients verbinden met één relay via WebSocket, en de relay handelt auth af, verifieert signatures, persisteert events, waaiert ze uit naar abonnees, indexeert ze voor zoeken, en triggert automatisering.

Alles is een Nostr-NIP-01-event. Elk event heeft zes velden: een id (SHA-256 van het geserialiseerde event), een pubkey, een kind-geheel getal, tags, content, en een Schnorr-signature. Het kind-geheel getal is de enige dispatch-schakelaar. Wil je een nieuwe feature? Definieer een nieuw kind-nummer. Bestaande clients zien niets en breken niets. De codebase definieert 81 kinds, waarbij eigen Buzz-kinds in het bereik 40000-49999 leven.

De ondersteunende stack is bewust saai, in de beste zin:

Postgres bewaart de events en draait het zoeken op volledige tekst. Redis handelt pub/sub-fan-out, aanwezigheid en typen af. S3-compatibele objectopslag (lokaal MinIO) bewaart media via het Blossom-protocol.

Het beveiligingsmodel is waar ik stopte met skimmen. Van elk event worden de Schnorr-signature en SHA-256-ID geverifieerd vóór opslag. NIP-42-auth gebruikt een ±60 seconden-tijdstempeltolerantie om replay-aanvallen te blokkeren, en auth-events worden nooit opgeslagen of geaudit. Het auditlog is een echte hash-chain: de SHA-256 van elke entry dekt elk veld inclusief de vorige hash, zodat het knoeien met één entry elke entry erna breekt. Uitgaande webhooks krijgen SSRF-bescherming die op private IP-bereiken controleert. En kanaallidmaatschap is de enige toegangspoort, afgedwongen bij elke operatie, waarbij de subscription-handler toegang controleert voordat hij een subscription registreert, zodat er geen race-venster is voor lekken van privékanalen.

Als je evalueert hoe je agentische AI deployt op infrastructuur die je beheerst, is dit het deel dat twee keer lezen waard is.

Wat vandaag werkt (en wat niet)

Het project is ongewoon eerlijk over zijn eigen status, en ik vind die eerlijkheid het sterkste signaal van een serieuze codebase. Hier is de huidige staat rechtstreeks uit de repo:

Nu het deel dat de meeste productposts overslaan. Het architectuurdoc noemt geverifieerde gaten, geen aspiraties:

• Er wordt nog geen rate limiting afgedwongen. De RateLimiter-trait bestaat en vier niveaus zijn ontworpen (human, agent-standard, agent-elevated, agent-platform), maar de enige implementatie is een test-stub.
• Goedkeuringsgates zijn niet end-to-end bedraad. De executor kan een run opschorten, maar een workflow die een goedkeuringsgate raakt wordt momenteel als mislukt gemarkeerd.
• Sommige workflow-acties zijn stubs. send_dm en set_channel_topic geven "not implemented" terug, zodat een run die er een bereikt faalt.
• Huddle-opname en per-track-publicatie zijn niet gebouwd. Voice-kamers en join/leave-levenscyclus werken; opname heeft gereserveerde event-kinds maar geen producer.
• Geen sqlx-offline-querycache. Query's draaien in runtime in plaats van geverifieerd te worden bij compiletijd.

Niets hiervan is diskwalificerend voor een zelf-gehoste tool die je evalueert, maar het vertelt je precies waar de randen zijn. Als je agents in productie moet evalueren met harde garanties, beschouw de 💭- en 🚧-kolommen dan als dragende waarschuwingen.

Aan de slag met Buzz

Er zijn drie paden, afhankelijk van wie je bent.

Gewoon proberen? Pak een verpakte build van de nieuwste release: macOS (.dmg), Linux (.AppImage of .deb), of Windows (.exe). Standaard verbindt hij met ws://localhost:3000, dus je wilt nog steeds een relay die draait.

Bouwen vanaf bron? Je hebt Docker nodig en ofwel Hermit of Rust 1.88+, Node 24+, pnpm 10+, en just. Dan:

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

De relay landt op ws://localhost:3000 en de desktop-app plopt op. Voor een single-node-VPS-deployment in plaats van de lokale-dev-stack is er een productie-Compose-bundle onder deploy/compose/ met Postgres, Redis, MinIO, en optioneel Caddy voor TLS.

Een agent meenemen? Zet BUZZ_PRIVATE_KEY en gebruik buzz-cli, die JSON in en JSON uit is, specifiek ontworpen voor LLM-tool-aanroepen. Dat is de naad waar je agentworkflows aankoppelen.

Wie zou Buzz moeten draaien?

Buzz is voor teams die één substraat willen in plaats van een stapel lijmcode. Als je huidige opstelling chat plus een forge plus bots plus CI-dashboards plus releasetools plus een zoekindex is, en je bent het zat dat ze niet van elkaar weten, dan is dit de weddenschap die Buzz aangaat: één community, één identiteitsmodel, één eventlog.

Het past goed bij:

• Zelf-hosters die hun agentverkeer op eigen infrastructuur willen, met een audittrail dat ze kunnen verifiëren.
• Platform-engineers die agent-first-workflows evalueren waarin agents bugs triëren, reviews draaien en releases opstellen als leden in plaats van scripts.
• Open-source-evaluateurs die het geheel in een middag willen lezen. Het agentoppervlak is twee crates zonder koppeling, bewust klein genoeg om te auditen.

Het is nog niet voor mensen die een afgemaakte, batteries-included SaaS willen die ze morgen aan een niet-technisch team kunnen geven. De goedkeuringsgates, rate limiting en mobiele clients landen nog. Buzz zegt je dit ronduit, wat precies de reden is waarom ik het een zorgvuldige pilot zou toevertrouwen.

De framing waar ik steeds op terugkom staat in de README: "Agents are part of the room, not haunted cron jobs." Als je ooit om 2 uur 's nachts een bot hebt gedebugd zonder idee wat hij deed of waarom, weet je al waarom dat ertoe doet.

FAQ

Is Buzz gratis en open source?

Ja. Buzz is open source onder de Apache 2.0-licentie en gebouwd door Block, Inc. Je host de relay zelf, dus er is geen per-seat-kost voor de software. Je kosten zijn je eigen infrastructuur: een server voor de relay, Postgres, Redis en objectopslag. De bron, issues en roadmap zijn allemaal openbaar op GitHub onder block/buzz.

Hoe verschilt Buzz van Slack met bots?

In Slack is een agent een tweedeklas bot met een aparte identiteit en audittrail, gescoped door permissievlaggen. In Buzz is een agent een eersteklas lid met een eigen sleutelpaar, kanaallidmaatschappen, en dezelfde mogelijkheden als een mens: repo's openen, patches sturen, workflows draaien, aan huddles deelnemen. Alles landt in één ondertekend, doorzoekbaar eventlog.

Wat zijn ACP en MCP?

ACP is het Agent Client Protocol, de stdio-interface die buzz-agent gebruikt om met een LLM-client zoals Zed te praten. MCP is het Model Context Protocol, de interface die buzz-dev-mcp gebruikt om een agent een shell en bestandseditor te geven. De twee binaries weten niets van elkaar; ze componeren via protocollen, zodat je agents en toolservers vrij kunt mengen.

Gebruikt Buzz blockchain?

Nee, en de README is er stellig over: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz gebruikt Nostr's cryptografische signatures en een hash-chain-auditlog voor manipulatiebewijs, maar er is geen token, geen chain en geen consensusmechanisme. Je krijgt verifieerbare geschiedenis zonder de overhead.

Kan ik mijn eigen AI-agents gebruiken, zoals Goose, Codex of Claude Code?

Ja. De buzz-acp-harness spawnt AI-agent-subprocessen en brugt relay-@mentions ernaartoe via ACP. Hij ondersteunt Goose, Codex en Claude Code out of the box, draait een pool van één tot 32 agentprocessen, en herstart een agent als hij crasht. Voor eigen tools koppel je je eigen MCP-server aan.

Is Buzz productie-klaar?

Deels. De relay, kanalen, zoeken, auditlog, desktop-app en agent-CLI werken vandaag. Maar rate limiting wordt niet afgedwongen, goedkeuringsgates zijn niet end-to-end bedraad, en mobiele clients zijn nog in ontwikkeling. Voor een zelf-gehoste pilot met een team dat ruwe randen tolereert, is het klaar om te proberen. Voor een compliance-kritieke deployment, wacht tot de 🚧-items landen.