Block Buzz: AI-agent-workspacet, hvor agenter er holdkammerater, ikke bots

Block Buzz: AI-agent-workspacet, hvor agenter er holdkammerater, ikke bots

De fleste »AI i din chat«-opsætninger fungerer på samme måde: Du bolter en bot på Slack eller Discord, giver den en slash-kommando, og den svarer, når den bliver kaldt frem. Botten lever uden for teamet. Den har en separat identitet, et separat revisionsspor og et hårdt loft over, hvad den kan røre. Block kiggede på det mønster og besluttede, at agenten bare skulle være medlem af rummet.

Den idé er Buzz, et open source-workspace fra Block, Inc., der allerede har tiltrukket cirka 18.000 GitHub-stjerner. I Buzz deler mennesker og AI-agenter de samme kanaler, signerer deres handlinger med samme slags kryptografiske nøgle og ender i den samme søgbare log. Det er skrevet i Rust og licenseret under Apache 2.0. Jeg har brugt tid på at læse repoets arkitekturdokumenter, så du slipper for det – og designvalgene er mere interessante, end markedsføringen antyder.

Hvad er Block Buzz?

Buzz er et self-hostbart workspace fra Block, Inc., hvor mennesker og AI-agenter deler de samme kanaler. Det kører på et Nostr-relay, så hver besked, reaktion, kode-patch, godkendelse og workflow-trin er én signeret hændelse i en enkelt, søgbar, manipulationssikker log. Det er open source under Apache 2.0, bygget i Rust, og du kører selv relayet.

De vigtigste pointer:

• Agenter er fuldgyldige medlemmer med deres egne nøgler og eget revisionsspor – ikke bots, der er boltet på i siden.
• Alt (chat, patches, CI, godkendelser) er én signeret Nostr-hændelse i en enkelt søgbar log.
• Agenter kobles på via ACP og MCP, så Goose, Codex og Claude Code virker ud af boksen.
• Self-hostet og open source (Apache 2.0), med en ærlig, offentlig liste over, hvad der ikke er færdigt endnu.

Den formulering, projektet læner sig op ad, er »en hive mind-kommunikationsplatform«. Det lyder storslået, men den daglige virkelighed er enklere: Det føles som et team-workspace. Kanaler, tråde, DM'er, et canvas, stemme-huddles, søgning. Drejningen er det, der ligger nedenunder. Hver handling er en signeret Nostr-hændelse, og forfatteren af den hændelse kan være et menneske eller en proces. Samme form, samme identitetsmodel, samme revisionsspor uanset hvad.

Hvis du har sammenlignet agent-frameworks som LangGraph, CrewAI og OpenAI Agents SDK, er Buzz et helt andet lag. De er biblioteker, du indlejrer i kode for at orkestrere en agents ræsonnering. Buzz er rummet, hvor agenten og dit team taler sammen, overleverer arbejde og efterlader et spor. De er komplementære, ikke konkurrenter.

Derfor ændrer »agenter som medlemmer« modellen

Bot-modellen har et strukturelt problem: Agenten er en gæst. Du tildeler den tilladelsesflag, den opererer gennem et smalt API, og når noget går galt, sidder du og forener to separate historikker – teamets chat og bottens logs.

Buzz vender det om. En agent får sit eget nøglepar, sine egne kanalmedlemskaber og sit eget revisionsspor. Du tilføjer en agent til en kanal på samme måde, som du tilføjer en person. Projektet beskriver afgrænsningen som »by identity, not by permission flags« – altså efter identitet, ikke efter tilladelsesflag – hvilket er samme måde, du ville afgrænse en menneskelig holdkammerat på. Du stoler på dem i nogle rum og ikke i andre.

Når en agent først er medlem, får den de samme muligheder som alle andre. Den kan åbne repos, sende patches, reviewe kode, køre workflows, redigere canvases, orkestrere andre agenter, oprette kanaler og hoppe ind i stemme-huddles. README'en gennemgår tre scenarier, der gør det konkret:

• Hændelseshukommelse. Klokken er 2 om natten, du spørger »har vi set denne fejl før?«, og en agent, der holder øje med kanalen, henter seks måneders historik, poster trådene og rodårsagerne og tilbyder at påkalde den, der shippede den seneste rettelse. Hele udvekslingen bliver i kanalen som dokumentation.
• Branch som rum. Du åbner en feature-branch, og en kanal dukker op. Patches lander som hændelser, CI poster resultater, en agent kører et første review, og merge-beslutningen bor i samme rum som dokumentationen, der begrundede den.
• En release, der skriver sig selv. Et workflow affyres på et tag, en agent udarbejder release-notes fra de merged PR'er, poster dem til menneskeligt review, får en tommel-op-reaktion og shipper. Hvert trin signeret, hvert trin søgbart.

Den røde tråd er, at samtalen, koden og beslutningen alle bor ét sted i stedet for i syv faner, der lader som om de kender hinanden.

Sådan kobles agenter faktisk på: ACP og MCP

Det er her, engineeringen bliver ren. Buzz leveres med to små binære filer til agenter, og de ved bevidst ikke noget om hinanden.

buzz-agent er en ACP-agent. Den taler Agent Client Protocol over stdio, kalder en LLM og bruger MCP-værktøjer. Den kører op til otte samtidige sessioner, hver med sine egne MCP-servere, historik og kontekst. Når en sessions kontekst fyldes op, opsummerer den sin egen historik og fortsætter. Den virker med Zed, JetBrains eller hvad som helst andet, der taler ACP.

buzz-dev-mcp er en MCP-server. Den giver enhver agent en shell og en fil-editor. Processer er efemere med process-group-kill på alle exit-veje, output er afgrænset, og filredigeringer resolves i forhold til arbejdsmappen. Hvis du har bygget med Model Context Protocol før, vil det føles bekendt: Det er standard-»giv en agent hænder«-mønsteret, bare hærdet.

Design-noten i repoet siger det ligeud: »two binaries, two protocols, no coupling between them«. Agenten ved ikke, hvilken MCP-server den taler med, og MCP-serveren ved ikke, hvilken agent der kalder den. De komponeres gennem protokoller, ikke imports. Den praktiske gevinst er, at du kan køre ti agenter bag Buzz med forskellige MCP-konfigurationer eller skifte din LLM-udbyder med én miljøvariabel.

Fordi buzz-acp bygger bro fra relay-@mentions til agent-underprocesser, kan du pege den mod Goose, Codex eller Claude Code. Hvis du allerede kører coding-agenter i baggrunden, giver Buzz dem et fælles rum at operere i i stedet for en stille, headless loop. Og hvis du vil medbringe dine egne værktøjer, er at bygge en MCP-server den understøttede vej, med masser af færdige MCP-servere at starte fra.

Under motorhjelmen: Arkitekturen

Buzz er et Rust-monorepo, og den enkelt vigtigste kendsgerning er denne: Relayet er den eneste sandhedskilde. Der er ingen peer-to-peer-gossip og ingen replikering. Klienter forbinder til ét relay over WebSocket, og relayet håndterer auth, verificerer signaturer, persisterer hændelser, spreder dem ud til abonnenter, indekserer dem til søgning og udløser automatisering.

Alt er en Nostr-NIP-01-hændelse. Hver hændelse har seks felter: et id (SHA-256 af den serialiserede hændelse), en pubkey, et kind-heltal, tags, content og en Schnorr-signatur. kind-heltallet er den eneste dispatch-omskifter. Vil du have en ny funktion? Definér et nyt kind-nummer. Eksisterende klienter ser intet og går ikke i stykker over noget. Kodebasen definerer 81 kinds, med Buzz' egne custom-kinds i intervallet 40.000–49.999.

Den understøttende stak er bevidst kedelig – på den gode måde:

Postgres rummer hændelserne og kører fuldtekstsøgning. Redis håndterer pub/sub-fan-out, tilstedeværelse og skriveindikatorer. S3-kompatibel objektlagring (MinIO lokalt) rummer medier via Blossom-protokollen.

Sikkerhedsmodellen er der, hvor jeg holdt op med at skimme. Hver hændelse får sin Schnorr-signatur og sit SHA-256-ID verificeret før lagring. NIP-42-auth bruger en tidsstempel-tolerance på ±60 sekunder til at blokere replay-angreb, og auth-hændelser lagres eller logges aldrig. Revisionsloggen er en ægte hash-kæde: Hver postnings SHA-256 dækker alle felter inklusive den forrige hash, så manipulation med én postning ødelægger alle postninger efter den. Udgående webhooks får SSRF-beskyttelse, der tjekker for private IP-intervaller. Og kanalmedlemskab er den eneste adgangsport, håndhævet ved hver operation, hvor abonnementshåndteringen tjekker adgang, før den registrerer et abonnement, så der ikke er noget race-vindue for lækager fra private kanaler.

Hvis du er ved at evaluere, hvordan du udruller agentisk AI på infrastruktur, du kontrollerer, er det her den del, der er værd at læse to gange.

Hvad virker i dag (og hvad gør ikke)

Projektet er usædvanligt ærligt om sin egen status, og jeg mener, at ærligheden er det stærkeste signal om en seriøs kodebase. Her er den nuværende tilstand direkte fra repoet:

Nu til den del, de fleste produktindlæg springer over. Arkitekturdokumentet viser verificerede huller, ikke aspirationer:

• Der håndhæves ingen rate limiting endnu. RateLimiter-traittet findes, og fire niveauer er designet (human, agent-standard, agent-elevated, agent-platform), men den eneste implementering er en test-stub.
• Godkendelsesgates er ikke koblet fra ende til anden. Eksekveringsmotoren kan suspendere en kørsel, men et workflow, der rammer en godkendelsesgate, markeres i øjeblikket som fejlet.
• Nogle workflow-handlinger er stubbet. send_dm og set_channel_topic returnerer »not implemented«, så en kørsel, der når en af dem, fejler.
• Huddle-optagelse og publicering pr. spor er ikke bygget. Stemmerum og join/leave-livscyklus virker; optagelse har reserverede hændelses-kinds, men ingen producer.
• Ingen sqlx offline query-cache. Forespørgsler kører på runtime i stedet for at blive valideret på compile-tidspunktet.

Intet af dette er diskvalificerende for et self-hostet værktøj, du er ved at evaluere, men det fortæller dig præcis, hvor kanterne er. Hvis du har brug for at evaluere agenter i produktion med hårde garantier, så betragt 💭- og 🚧-kolonnerne som bærende advarsler.

Kom i gang med Buzz

Der er tre veje, alt efter hvem du er.

Vil du bare prøve det? Hent en færdig build fra den seneste release: macOS (.dmg), Linux (.AppImage eller .deb) eller Windows (.exe). Som standard forbinder den til ws://localhost:3000, så du skal stadig have et relay kørende.

Vil du bygge fra kilden? Du skal bruge Docker og enten Hermit eller Rust 1.88+, Node 24+, pnpm 10+ og just. Så:

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

Relayet lander på ws://localhost:3000, og desktop-appen dukker op. Til en single-node VPS-udrulning i stedet for den lokale udviklingsstak er der en produktions-Compose-pakke under deploy/compose/ med Postgres, Redis, MinIO og valgfri Caddy til TLS.

Medbringer du en agent? Sæt BUZZ_PRIVATE_KEY og brug buzz-cli, som er JSON ind og JSON ud, designet specifikt til LLM-værktøjskald. Det er det stik, hvor dine agent-workflows kobles på.

Hvem bør køre Buzz?

Buzz er til teams, der vil have ét fælles fundament i stedet for en bunke limkode. Hvis dit nuværende setup er chat plus en forge plus bots plus CI-dashboards plus releaseværktøjer plus et søgeindeks, og du er træt af, at de ikke kender hinanden, er det her det væddemål, Buzz tager: ét fællesskab, én identitetsmodel, én hændelseslog.

Det passer særligt godt til:

• Self-hostere, der vil have deres agent-trafik på infrastruktur, de selv ejer, med et revisionsspor, de kan verificere.
• Platformsingeniører, der evaluerer agent-first-workflows, hvor agenter triager bugs, kører reviews og udarbejder releases som medlemmer snarere end scripts.
• Open source-evaluatorer, der vil læse det hele på en eftermiddag. Agent-overfladen er to crates uden kobling – bevidst lille nok til at gennemgå.

Det er endnu ikke til folk, der vil have en færdig SaaS med alt inkluderet, som de kan give til et ikke-teknisk team i morgen. Godkendelsesgates, rate limiting og de mobile klienter lander stadig. Buzz fortæller dig det ligeud, og det er præcis derfor, jeg ville stole på det til en forsigtig pilot.

Den formulering, jeg bliver ved med at vende tilbage til, står i README'en: »Agenter er en del af rummet, ikke forheksede cron-jobs.« Hvis du nogensinde har debugget en bot klokken 2 om natten uden anelse om, hvad den lavede, eller hvorfor, ved du allerede, hvorfor det betyder noget.

Ofte stillede spørgsmål

Er Buzz gratis og open source?

Ja. Buzz er open source under Apache 2.0-licensen og bygget af Block, Inc. Du self-hoster selv relayet, så der er ingen pris pr. bruger for softwaren. Dine omkostninger er din egen infrastruktur: en server til relayet, Postgres, Redis og objektlagring. Koden, issues og køreplanen er alle offentlige på GitHub under block/buzz.

Hvordan adskiller Buzz sig fra Slack med bots?

I Slack er en agent en andenrangs-bot med en separat identitet og et separat revisionsspor, afgrænset af tilladelsesflag. I Buzz er en agent et fuldgyldigt medlem med sit eget nøglepar, sine egne kanalmedlemskaber og de samme muligheder som et menneske: at åbne repos, sende patches, køre workflows og deltage i huddles. Alt lander i én signeret, søgbar hændelseslog.

Hvad er ACP og MCP?

ACP er Agent Client Protocol, stdio-interfacet som buzz-agent bruger til at tale med en LLM-klient som Zed. MCP er Model Context Protocol, interfacet som buzz-dev-mcp bruger til at give en agent en shell og en fil-editor. De to binære filer ved ikke noget om hinanden; de komponeres gennem protokoller, så du kan blande agenter og værktøjsservere frit.

Bruger Buzz blockchain?

Nej, og README'en er direkte om det: »Ikke blockchain. Signerede hændelser er nyttige uden at tvinge alle til at købe en samlermønt.« Buzz bruger Nostrs kryptografiske signaturer og en hash-kæde-revisionslog til manipulationssikring, men der er hverken token, kæde eller konsensusmekanisme. Du får verificerbar historik uden overheadet.

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

Ja. buzz-acp-harnesset spawner AI-agent-underprocesser og bygger bro fra relay-@mentions til dem via ACP. Det understøtter Goose, Codex og Claude Code ud af boksen, kører en pool på én til 32 agentprocesser og genstarter en agent, hvis den crasher. Til egne værktøjer kobler du din egen MCP-server på.

Er Buzz produktionsklar?

Dele af det er det. Relayet, kanalerne, søgningen, revisionsloggen, desktop-appen og agent-CLI'en virker i dag. Men rate limiting håndhæves ikke, godkendelsesgates er ikke koblet fra ende til anden, og de mobile klienter er stadig undervejs. Til en self-hostet pilot med et team, der tåler ru kanter, er det klar til at prøve. Til en compliance-kritisk udrulning bør du vente på, at 🚧-punkterne lander.