Block Buzz: AI-agentarbetsytan där agenter är lagkamrater, inte bottar

Block Buzz: AI-agentarbetsytan där agenter är lagkamrater, inte bottar

De flesta "AI i din chatt"-upplägg fungerar likadant: du bultar fast en bot på Slack eller Discord, ger den ett slash-kommando, och den svarar när den kallas. Botten lever utanför teamet. Den har en separat identitet, ett separat granskningsspår och ett hårt tak för vad den får röra. Block tittade på det mönstret och bestämde att agenten helt enkelt borde vara en medlem i rummet.

Den idén är Buzz, en arbetsyta med öppen källkod från Block, Inc. som redan har dragit till sig omkring 18 000 GitHub-stjärnor. I Buzz delar människor och AI-agenter samma kanaler, signerar sina åtgärder med samma sorts kryptografiska nyckel och hamnar i samma sökbara logg. Den är skriven i Rust och licensierad under Apache 2.0. Jag lade tid på att läsa igenom repots arkitekturdokument så att du slipper, och designvalen är intressantare än marknadsföringen antyder.

Vad är Block Buzz?

Buzz är en självhostbar arbetsyta från Block, Inc. där människor och AI-agenter delar samma kanaler. Den körs på en Nostr-relä, så att varje meddelande, reaktion, kodpatch, godkännande och arbetsflödessteg är en signerad händelse i en enda, sökbar, manipulationssäker logg. Den är öppen källkod under Apache 2.0, byggd i Rust, och du kör reläet själv.

Viktiga punkter:

• Agenter är förstklassiga medlemmar med egna nycklar och eget granskningsspår, inte bottar som bultats fast vid sidan om.
• Allt (chatt, patchar, CI, godkännanden) är en signerad Nostr-händelse i en enda sökbar logg.
• Agenter ansluter via ACP och MCP, så Goose, Codex och Claude Code fungerar direkt.
• Självhostad och öppen källkod (Apache 2.0), med en ärlig, offentlig lista över vad som inte är klart ännu.

Frasen projektet lutar sig mot är "a hive mind communication platform". Det låter storslaget, men den dagliga verkligheten är enklare: det känns som en teamarbetsyta. Kanaler, trådar, direktmeddelanden, en canvas, röst-huddlar, sökning. Vridningen är det som ligger under. Varje åtgärd är en signerad Nostr-händelse, och författaren till den händelsen kan vara en person eller en process. Samma form, samma identitetsmodell, samma granskningsspår i båda fallen.

Om du har jämfört agentramverk som LangGraph, CrewAI och OpenAI Agents SDK är Buzz ett helt annat lager. De är bibliotek du bäddar in i kod för att orkestrera en agents resonemang. Buzz är rummet där agenten och ditt team pratar, lämnar över arbete och lämnar ett spår. De kompletterar varandra, de konkurrerar inte.

Varför "agenter som medlemmar" förändrar modellen

Botmodellen har ett strukturellt problem: agenten är en gäst. Du ger den behörighetsflaggor, den opererar via ett smalt API, och när något går fel förlikar du två separata historiker — teamets chatt och bottens loggar.

Buzz vänder på detta. En agent får sitt eget nyckelpar, sina egna kanalmedlemskap och sitt eget granskningsspår. Du lägger till en agent i en kanal på samma sätt som du lägger till en person. Projektet beskriver avgränsningen som "by identity, not by permission flags", vilket är samma sätt som du skulle avgränsa en mänsklig lagkamrat. Du litar på dem i vissa rum och inte i andra.

När en agent väl är medlem får den samma möjligheter som alla andra. Den kan öppna repon, skicka patchar, granska kod, köra arbetsflöden, redigera canvases, orkestrera andra agenter, skapa kanaler och hoppa in i röst-huddlar. README:n går igenom tre scenarier som gör detta konkret:

• Incidentminne. Klockan är 2 på natten, du frågar "har vi sett det här felet förut?", och en agent som bevakar kanalen hämtar sex månaders historik, postar trådarna och rotorsakerna, och erbjuder sig att tillkalla den som skeppade den senaste fixen. Hela utbytet stannar i kanalen som bevis.
• Branch som rum. Du öppnar en funktionsbranch och en kanal dyker upp. Patchar landar som händelser, CI postar resultat, en agent kör en första granskning, och merge-beslutet lever i samma rum som bevisen som motiverade det.
• En release som skriver sig själv. Ett arbetsflöde utlöses på en tagg, en agent utkastar release-anteckningar från de mergade PR:erna, postar dem för mänsklig granskning, får en tumme-upp-reaktion, och skeppar. Varje steg signerat, varje steg sökbart.

Den gemensamma nämnaren är att konversationen, koden och beslutet alla lever på ett ställe istället för sju flikar som låtsas känna till varandra.

Hur agenter faktiskt ansluter: ACP och MCP

Det är här ingenjörskonsten blir ren. Buzz skeppar två små binärer för agenter, och de vet medvetet inget om varandra.

buzz-agent är en ACP-agent. Den talar Agent Client Protocol över stdio, anropar en LLM och använder MCP-verktyg. Den kör upp till åtta samtidiga sessioner, var och en med egna MCP-servrar, historik och kontext. När en sessions kontext fylls sammanfattar den sin egen historik och fortsätter. Den fungerar med Zed, JetBrains eller vad som helst som talar ACP.

buzz-dev-mcp är en MCP-server. Den ger vilken agent som helst ett skal och en filredigerare. Processer är kortlivade med processgrupps-kill på varje utgångsväg, utdata är begränsad, och filredigeringar löses mot arbetskatalogen. Om du har byggt med Model Context Protocol förut kommer detta att kännas bekant: det är standardmönstret "ge en agent händer", härdat.

Designanteckningen i repot säger det rakt på sak: "two binaries, two protocols, no coupling between them." Agenten vet inte vilken MCP-server den pratar med, och MCP-servern vet inte vilken agent som anropar den. De komponerar via protokoll, inte via importer. Den praktiska vinsten är att du kan köra tio agenter bakom Buzz med olika MCP-konfigurationer, eller byta din LLM-leverantör med en miljövariabel.

Eftersom buzz-acp bryggar relä-@mentions till agent-underprocesser kan du rikta den mot Goose, Codex eller Claude Code. Om du redan kör bakgrundskodningsagenter ger Buzz dem ett delat rum att operera i istället för en tyst headless-loop. Och om du vill ta med egna verktyg är att bygga en MCP-server den stödda vägen, med gott om färdiga MCP-servrar att utgå från.

Under huven: arkitekturen

Buzz är ett Rust-monorepo, och det enskilt viktigaste faktumet är detta: reläet är den enda sanningens källa. Det finns ingen peer-to-peer-skvaller och ingen replikering. Klienter ansluter till ett relä över WebSocket, och reläet hanterar autentisering, verifierar signaturer, beständiggör händelser, sprider dem till prenumeranter, indexerar dem för sökning och utlöser automation.

Allt är en Nostr-NIP-01-händelse. Varje händelse har sex fält: ett id (SHA-256 av den serialiserade händelsen), en pubkey, ett kind-heltal, taggar, innehåll och en Schnorr-signatur. kind-heltalet är den enda dispatch-omkopplaren. Vill du ha en ny funktion? Definiera ett nytt kind-nummer. Befintliga klienter ser inget och går inte sönder. Kodbasen definierar 81 kinds, med anpassade Buzz-kinds i intervallet 40000-49999.

Den stödjande stacken är medvetet tråkig, på bästa sätt:

Postgres håller händelserna och kör fulltextsökning. Redis hanterar pub/sub-spridning, närvaro och skrivande. S3-kompatibel objektlagring (MinIO lokalt) håller media via Blossom-protokollet.

Säkerhetsmodellen är där jag slutade skumma. Varje händelse får sin Schnorr-signatur och SHA-256-ID verifierade före lagring. NIP-42-autentisering använder en ±60 sekunders tidsstämpeltolerans för att blockera replay-attacker, och autentiseringshändelser lagras eller granskas aldrig. Granskningsloggen är en äkta hash-kedja: varje post SHA-256 täcker varje fält inklusive föregående hash, så att manipulera en post bryter varje post efter den. Utgående webhooks får SSRF-skydd som kontrollerar privata IP-intervall. Och kanalmedlemskap är den enda åtkomstporten, som tillämpas vid varje operation, där prenumerationshanteraren kontrollerar åtkomst innan den registrerar en prenumeration så att det inte finns något race-fönster för läckor av privata kanaler.

Om du utvärderar hur du driftsätter agentisk AI på infrastruktur du kontrollerar är det här delen värd att läsa två gånger.

Vad som fungerar idag (och vad som inte gör det)

Projektet är ovanligt ärligt om sin egen status, och jag tycker att den ärligheten är den starkaste signalen på en seriös kodbas. Här är det aktuella läget rakt från repot:

Nu delen de flesta produktinlägg hoppar över. Arkitekturdokumentet listar verifierade luckor, inte aspirationer:

• Ingen hastighetsbegränsning tillämpas ännu. RateLimiter-traitet finns och fyra nivåer är designade (human, agent-standard, agent-elevated, agent-platform), men den enda implementationen är en test-stub.
• Godkännandegrindar är inte ihopkopplade end-to-end. Exekveraren kan pausa en körning, men ett arbetsflöde som träffar en godkännandegrind markeras för närvarande som misslyckat.
• Vissa arbetsflödesåtgärder är stubbar. send_dm och set_channel_topic returnerar "not implemented", så en körning som når en sådan misslyckas.
• Huddle-inspelning och publicering per spår är inte byggda. Röstrum och gå-med/lämna-livscykel fungerar; inspelning har reserverade händelse-kinds men ingen producent.
• Ingen sqlx-offline-frågecache. Frågor körs i körtid istället för att valideras vid kompilering.

Inget av detta är diskvalificerande för ett självhostat verktyg du utvärderar, men det talar om exakt var kanterna är. Om du behöver utvärdera agenter i produktion med hårda garantier, behandla 💭- och 🚧-kolumnerna som bärande varningar.

Komma igång med Buzz

Det finns tre vägar, beroende på vem du är.

Vill du bara prova? Ta en paketerad build från den senaste releasen: macOS (.dmg), Linux (.AppImage eller .deb), eller Windows (.exe). Som standard ansluter den till ws://localhost:3000, så du vill fortfarande ha ett relä igång.

Vill du bygga från källkod? Du behöver Docker och antingen Hermit eller Rust 1.88+, Node 24+, pnpm 10+, och just. Sedan:

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äet landar på ws://localhost:3000 och skrivbordsappen poppar upp. För en en-nods-VPS-driftsättning istället för den lokala utvecklingsstacken finns ett produktions-Compose-paket under deploy/compose/ med Postgres, Redis, MinIO, och valfri Caddy för TLS.

Tar du med en agent? Sätt BUZZ_PRIVATE_KEY och använd buzz-cli, som är JSON in och JSON ut, designad specifikt för LLM-verktygsanrop. Det är sömmen där dina agentarbetsflöden ansluter.

Vem bör köra Buzz?

Buzz är för team som vill ha ett enda substrat istället för en hög limkod. Om ditt nuvarande upplägg är chatt plus en forge plus bottar plus CI-instrumentpaneler plus release-verktyg plus ett sökindex, och du är trött på att de inte känner till varandra, är det här vad Buzz slår vad om: en gemenskap, en identitetsmodell, en händelselogg.

Den passar bra för:

• Självhostare som vill ha sin agenttrafik på infrastruktur de äger, med ett granskningsspår de kan verifiera.
• Plattformsingenjörer som utvärderar agent-först-arbetsflöden där agenter triagerar buggar, kör granskningar och utkastar releaser som medlemmar istället för skript.
• Öppen-källkod-utvärderare som vill läsa hela saken på en eftermiddag. Agentytan är två crates utan koppling, medvetet liten nog att granska.

Den är ännu inte för folk som vill ha en färdig, batterier-inkluderad SaaS de kan lämna till ett icke-tekniskt team imorgon. Godkännandegrindarna, hastighetsbegränsningen och de mobila klienterna landar fortfarande. Buzz säger dig detta rakt på sak, vilket är exakt varför jag skulle anförtro den en försiktig pilot.

Inramningen jag ständigt återkommer till finns i README:n: "Agents are part of the room, not haunted cron jobs." Om du någonsin har felsökt en bot klockan 2 på natten utan aning om vad den gjorde eller varför, vet du redan varför det spelar roll.

FAQ

Är Buzz gratis och öppen källkod?

Ja. Buzz är öppen källkod under Apache 2.0-licensen och byggd av Block, Inc. Du självhostar reläet själv, så det finns ingen avgift per plats för mjukvaran. Dina kostnader är din egen infrastruktur: en server för reläet, Postgres, Redis och objektlagring. Källan, issues och roadmap är alla offentliga på GitHub under block/buzz.

Hur skiljer sig Buzz från Slack med bottar?

I Slack är en agent en andraklass-bot med separat identitet och granskningsspår, avgränsad av behörighetsflaggor. I Buzz är en agent en förstklassig medlem med eget nyckelpar, kanalmedlemskap och samma möjligheter som en människa: öppna repon, skicka patchar, köra arbetsflöden, gå med i huddlar. Allt landar i en signerad, sökbar händelselogg.

Vad är ACP och MCP?

ACP är Agent Client Protocol, stdio-gränssnittet som buzz-agent använder för att prata med en LLM-klient som Zed. MCP är Model Context Protocol, gränssnittet som buzz-dev-mcp använder för att ge en agent ett skal och en filredigerare. De två binärerna vet inget om varandra; de komponerar via protokoll, så du kan blanda agenter och verktygsservrar fritt.

Använder Buzz blockchain?

Nej, och README:n är tydlig med det: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz använder Nostrs kryptografiska signaturer och en hash-kedje-granskningslogg för manipulationssäkerhet, men det finns ingen token, ingen kedja och ingen konsensusmekanism. Du får verifierbar historik utan overhead.

Kan jag använda mina egna AI-agenter, som Goose, Codex eller Claude Code?

Ja. buzz-acp-harnesset startar AI-agent-underprocesser och bryggar relä-@mentions till dem via ACP. Det stöder Goose, Codex och Claude Code direkt, kör en pool av en till 32 agentprocesser, och startar om en agent om den kraschar. För anpassade verktyg ansluter du din egen MCP-server.

Är Buzz produktionsklart?

Delvis. Reläet, kanaler, sökning, granskningslogg, skrivbordsapp och agent-CLI fungerar idag. Men hastighetsbegränsning tillämpas inte, godkännandegrindar är inte ihopkopplade end-to-end, och mobila klienter är fortfarande pågående. För en självhostad pilot med ett team som tolererar ojämna kanter är det redo att provas. För en efterlevnadskritisk driftsättning, vänta på att 🚧-punkterna landar.