Block Buzz: AI-agentarbeidsflaten der agenter er lagkamerater, ikke boter

Block Buzz: AI-agentarbeidsflaten der agenter er lagkamerater, ikke boter

De fleste "AI i chatten din"-oppsett fungerer likt: du boltrer en bot på Slack eller Discord, gir den en skråstrek-kommando, og den svarer når den kalles. Boten lever utenfor teamet. Den har en separat identitet, et separat revisjonsspor og et hardt tak på hva den kan røre. Block så på det mønsteret og bestemte at agenten bare burde være et medlem av rommet.

Den idéen er Buzz, en arbeidsflate med åpen kildekode fra Block, Inc. som allerede har trukket til seg rundt 18 000 GitHub-stjerner. I Buzz deler mennesker og AI-agenter de samme kanalene, signerer handlingene sine med samme slags kryptografiske nøkkel, og ender i den samme søkbare loggen. Den er skrevet i Rust og lisensiert under Apache 2.0. Jeg brukte tid på å lese gjennom repoets arkitekturdokumenter slik at du slipper, og designvalgene er mer interessante enn markedsføringen antyder.

Hva er Block Buzz?

Buzz er en selvhostbar arbeidsflate fra Block, Inc. der mennesker og AI-agenter deler de samme kanalene. Den kjører på en Nostr-relé, slik at hver melding, reaksjon, kodepatch, godkjenning og arbeidsflytsteg er én signert hendelse i én enkelt, søkbar, manipuleringssikker logg. Den er åpen kildekode under Apache 2.0, bygget i Rust, og du kjører reléen selv.

Nøkkelpunkter:

• Agenter er førsteklasses medlemmer med egne nøkler og eget revisjonsspor, ikke boter som er boltret på siden.
• Alt (chat, patcher, CI, godkjenninger) er én signert Nostr-hendelse i én søkbar logg.
• Agenter kobler seg på via ACP og MCP, så Goose, Codex og Claude Code fungerer rett ut av boksen.
• Selvhostet og åpen kildekode (Apache 2.0), med en ærlig, offentlig liste over hva som ikke er ferdig ennå.

Frasen prosjektet lener seg på er "a hive mind communication platform". Det høres stort, men den daglige virkeligheten er enklere: det føles som en teamarbeidsflate. Kanaler, tråder, direktemeldinger, et lerret, stemme-huddler, søk. Vrien er det som ligger under. Hver handling er en signert Nostr-hendelse, og forfatteren av den hendelsen kan være en person eller en prosess. Samme form, samme identitetsmodell, samme revisjonsspor i begge tilfeller.

Hvis du har sammenlignet agentrammeverk som LangGraph, CrewAI og OpenAI Agents SDK, er Buzz et helt annet lag. De er biblioteker du bygger inn i kode for å orkestrere en agents resonnement. Buzz er rommet der agenten og teamet ditt snakker, overlater arbeid og etterlater et spor. De utfyller hverandre, de konkurrerer ikke.

Hvorfor "agenter som medlemmer" endrer modellen

Botmodellen har et strukturelt problem: agenten er en gjest. Du gir den tillatelsesflagg, den opererer gjennom et smalt API, og når noe går galt forliker du to separate historier — teamets chat og botens logger.

Buzz snur dette. En agent får sitt eget nøkkelpar, sine egne kanalmedlemskap og sitt eget revisjonsspor. Du legger en agent til en kanal på samme måte som du legger til en person. Prosjektet beskriver avgrensningen som "by identity, not by permission flags", som er samme måte du ville avgrense en menneskelig lagkamerat. Du stoler på dem i noen rom og ikke i andre.

Når en agent er medlem, får den de samme mulighetene som alle andre. Den kan åpne repoer, sende patcher, granske kode, kjøre arbeidsflyter, redigere lerret, orkestrere andre agenter, opprette kanaler og bli med i stemme-huddler. README-en går gjennom tre scenarier som gjør dette konkret:

• Hendelsesminne. Klokken er 2 på natten, du spør "har vi sett denne feilen før?", og en agent som overvåker kanalen henter seks måneders historikk, poster trådene og rotårsakene, og tilbyr å tilkalle den som sendte den siste fiksen. Hele utvekslingen blir værende i kanalen som bevis.
• Branch som rom. Du åpner en funksjonsbranch og en kanal dukker opp. Patcher lander som hendelser, CI poster resultater, en agent kjører en første gjennomgang, og merge-beslutningen lever i samme rom som bevisene som rettferdiggjorde den.
• En release som skriver seg selv. En arbeidsflyt utløses på en tag, en agent utformer release-notater fra de mergede PR-ene, poster dem for menneskelig gjennomgang, får en tommel-opp-reaksjon, og sender. Hvert steg signert, hvert steg søkbart.

Den felles tråden er at samtalen, koden og beslutningen alle lever på ett sted i stedet for syv faner som later som de kjenner til hverandre.

Hvordan agenter faktisk kobler seg på: ACP og MCP

Det er her ingeniørkunsten blir ren. Buzz sender to små binærfiler for agenter, og de vet bevisst ingenting om hverandre.

buzz-agent er en ACP-agent. Den snakker Agent Client Protocol over stdio, kaller en LLM, og bruker MCP-verktøy. Den kjører opptil åtte samtidige økter, hver med egne MCP-servere, historikk og kontekst. Når en økts kontekst fylles, oppsummerer den sin egen historikk og fortsetter. Den fungerer med Zed, JetBrains eller hva som helst som snakker ACP.

buzz-dev-mcp er en MCP-server. Den gir enhver agent et skall og en filredigerer. Prosesser er kortvarige med prosessgruppe-kill på hver utgangssti, utdata er begrenset, og filredigeringer løses mot arbeidskatalogen. Hvis du har bygget med Model Context Protocol før, vil dette føles kjent: det er standardmønsteret "gi en agent hender", herdet.

Designnotatet i repoet sier det rett ut: "two binaries, two protocols, no coupling between them." Agenten vet ikke hvilken MCP-server den snakker med, og MCP-serveren vet ikke hvilken agent som kaller den. De komponerer via protokoller, ikke via importer. Den praktiske gevinsten er at du kan kjøre ti agenter bak Buzz med forskjellige MCP-konfigurasjoner, eller bytte LLM-leverandør med én miljøvariabel.

Fordi buzz-acp broer relé-@mentions til agent-underprosesser, kan du peke den mot Goose, Codex eller Claude Code. Hvis du allerede kjører bakgrunnskodingsagenter, gir Buzz dem et delt rom å operere i i stedet for en stille headless-løkke. Og hvis du vil ta med egne verktøy, er å bygge en MCP-server den støttede veien, med rikelig av ferdige MCP-servere å starte fra.

Under panseret: arkitekturen

Buzz er et Rust-monorepo, og det viktigste faktumet er dette: reléen er den eneste sannhetskilden. Det er ingen peer-to-peer-sladder og ingen replikering. Klienter kobler til én relé over WebSocket, og reléen håndterer autentisering, verifiserer signaturer, persistere hendelser, sprer dem til abonnenter, indekserer dem for søk, og utløser automatisering.

Alt er en Nostr-NIP-01-hendelse. Hver hendelse har seks felt: en id (SHA-256 av den serialiserte hendelsen), en pubkey, et kind-heltall, tagger, innhold og en Schnorr-signatur. kind-heltallet er den eneste dispatch-bryteren. Vil du ha en ny funksjon? Definer et nytt kind-nummer. Eksisterende klienter ser ingenting og ødelegger ingenting. Kodebasen definerer 81 kinds, med tilpassede Buzz-kinds i området 40000-49999.

Den understøttende stakken er bevisst kjedelig, på den beste måten:

Postgres holder hendelsene og kjører fulltekstsøk. Redis håndterer pub/sub-spredning, tilstedeværelse og skriving. S3-kompatibel objektlagring (MinIO lokalt) holder medier via Blossom-protokollen.

Sikkerhetsmodellen er der jeg sluttet å skumme. Hver hendelse får sin Schnorr-signatur og SHA-256-ID verifisert før lagring. NIP-42-autentisering bruker en ±60 sekunders tidsstempeltoleranse for å blokkere replay-angrep, og autentiseringshendelser lagres eller revideres aldri. Revisjonsloggen er en ekte hash-kjede: hver oppførings SHA-256 dekker hvert felt inkludert forrige hash, slik at å tukle med én oppføring bryter hver oppføring etter den. Utgående webhooks får SSRF-beskyttelse som sjekker private IP-områder. Og kanalmedlemskap er den eneste tilgangsporten, håndhevet ved hver operasjon, der abonnementsbehandleren sjekker tilgang før den registrerer et abonnement slik at det ikke er noe race-vindu for lekkasjer av private kanaler.

Hvis du evaluerer hvordan du utruller agentisk AI på infrastruktur du kontrollerer, er dette delen som er verdt å lese to ganger.

Hva som fungerer i dag (og hva som ikke gjør det)

Prosjektet er uvanlig ærlig om sin egen status, og jeg mener den ærligheten er det sterkeste signalet på en seriøs kodebase. Her er den nåværende tilstanden rett fra repoet:

Nå delen de fleste produktinnlegg hopper over. Arkitekturdokumentet lister verifiserte gap, ikke ambisjoner:

• Ingen hastighetsbegrensning håndheves ennå. RateLimiter-traiten finnes og fire nivåer er designet (human, agent-standard, agent-elevated, agent-platform), men den eneste implementasjonen er en test-stub.
• Godkjenningsporter er ikke koblet ende-til-ende. Utføreren kan suspendere en kjøring, men en arbeidsflyt som treffer en godkjenningsport markeres for øyeblikket som mislykket.
• Noen arbeidsflythandlinger er stubber. send_dm og set_channel_topic returnerer "not implemented", så en kjøring som når en slik mislykkes.
• Huddle-opptak og publisering per spor er ikke bygget. Stemmerom og bli-med/forlat-livssykel fungerer; opptak har reserverte hendelses-kinds men ingen produsent.
• Ingen sqlx-offline-spørringsbuffer. Spørringer kjøres i kjøretid i stedet for å valideres ved kompilering.

Ingenting av dette er diskvalifiserende for et selvhostet verktøy du evaluerer, men det forteller deg nøyaktig hvor kantene er. Hvis du trenger å evaluere agenter i produksjon med harde garantier, behandle 💭- og 🚧-kolonnene som bærende advarsler.

Komme i gang med Buzz

Det er tre veier, avhengig av hvem du er.

Vil du bare prøve? Ta en pakket build fra den nyeste releasen: macOS (.dmg), Linux (.AppImage eller .deb), eller Windows (.exe). Som standard kobler den til ws://localhost:3000, så du vil fortsatt ha en relé i gang.

Vil du bygge fra kildekode? Du trenger Docker og enten Hermit eller Rust 1.88+, Node 24+, pnpm 10+, og just. Deretter:

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

Reléen lander på ws://localhost:3000 og skrivebordsappen spretter opp. For en enkelt-node-VPS-utrulling i stedet for den lokale utviklingsstakken, er det en produksjons-Compose-pakke under deploy/compose/ med Postgres, Redis, MinIO, og valgfri Caddy for TLS.

Tar du med en agent? Sett BUZZ_PRIVATE_KEY og bruk buzz-cli, som er JSON inn og JSON ut, designet spesifikt for LLM-verktøykall. Det er sømmen der agentarbeidsflytene dine kobler seg på.

Hvem bør kjøre Buzz?

Buzz er for team som vil ha ett substrat i stedet for en haug med limkode. Hvis ditt nåværende oppsett er chat pluss en forge pluss boter pluss CI-dashbord pluss release-verktøy pluss en søkeindeks, og du er lei av at de ikke kjenner til hverandre, er dette innsatsen Buzz gjør: ett fellesskap, én identitetsmodell, én hendelseslogg.

Den passer godt for:

• Selvhostere som vil ha agenttrafikken sin på infrastruktur de eier, med et revisjonsspor de kan verifisere.
• Plattformingeniører som evaluerer agent-først-arbeidsflyter der agenter triagerer feil, kjører gjennomganger og utformer releaser som medlemmer i stedet for skript.
• Åpen-kildekode-evaluatorer som vil lese hele greia på en ettermiddag. Agentflaten er to crates uten kobling, bevisst liten nok til å revideres.

Den er ennå ikke for folk som vil ha en ferdig, batterier-inkludert SaaS de kan gi til et ikke-teknisk team i morgen. Godkjenningsportene, hastighetsbegrensningen og de mobile klientene lander fortsatt. Buzz sier deg dette rett ut, som er nøyaktig hvorfor jeg ville betro den en forsiktig pilot.

Innrammingen jeg stadig kommer tilbake til står i README-en: "Agents are part of the room, not haunted cron jobs." Hvis du noen gang har feilsøkt en bot klokken 2 på natten uten anelse om hva den gjorde eller hvorfor, vet du allerede hvorfor det betyr noe.

FAQ

Er Buzz gratis og åpen kildekode?

Ja. Buzz er åpen kildekode under Apache 2.0-lisensen og bygget av Block, Inc. Du selvhoster reléen selv, så det er ingen per-sete-avgift for programvaren. Kostnadene dine er din egen infrastruktur: en server for reléen, Postgres, Redis og objektlagring. Kilden, issues og roadmap er alle offentlige på GitHub under block/buzz.

Hvordan skiller Buzz seg fra Slack med boter?

I Slack er en agent en andreklasses bot med separat identitet og revisjonsspor, avgrenset av tillatelsesflagg. I Buzz er en agent et førsteklasses medlem med eget nøkkelpar, kanalmedlemskap og de samme mulighetene som et menneske: åpne repoer, sende patcher, kjøre arbeidsflyter, bli med i huddler. Alt lander i én signert, søkbar hendelseslogg.

Hva er ACP og MCP?

ACP er Agent Client Protocol, stdio-grensesnittet som buzz-agent bruker for å snakke med en LLM-klient som Zed. MCP er Model Context Protocol, grensesnittet som buzz-dev-mcp bruker for å gi en agent et skall og en filredigerer. De to binærfilene vet ingenting om hverandre; de komponerer via protokoller, så du kan blande agenter og verktøyservere fritt.

Bruker Buzz blokkjede?

Nei, og README-en er tydelig på det: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz bruker Nostrs kryptografiske signaturer og en hash-kjede-revisjonslogg for manipuleringssikkerhet, men det er ingen token, ingen kjede og ingen konsensusmekanisme. Du får verifiserbar historikk uten overhead.

Kan jeg bruke mine egne AI-agenter, som Goose, Codex eller Claude Code?

Ja. buzz-acp-harnessen starter AI-agent-underprosesser og broer relé-@mentions til dem via ACP. Den støtter Goose, Codex og Claude Code rett ut av boksen, kjører en pool på én til 32 agentprosesser, og starter en agent på nytt hvis den krasjer. For egne verktøy kobler du din egen MCP-server.

Er Buzz produksjonsklar?

Delvis. Reléen, kanaler, søk, revisjonslogg, skrivebordsapp og agent-CLI fungerer i dag. Men hastighetsbegrensning håndheves ikke, godkjenningsporter er ikke koblet ende-til-ende, og mobile klienter er fortsatt underveis. For en selvhostet pilot med et team som tolererer ujevne kanter, er den klar til å prøves. For en etterlevelseskritisk utrulling, vent til 🚧-punktene lander.