Block Buzz: Workspace pro AI agenty, kde jsou agenti členové týmu, ne boti

Block Buzz: Workspace pro AI agenty, kde jsou agenti členové týmu, ne boti

Většina nastavení typu „AI ve vašem chatu" funguje stejně: přišroubujete bota na Slack nebo Discord, dáte mu slash příkaz a on odpoví, když ho zavoláte. Bot žije mimo tým. Má oddělenou identitu, oddělenou auditní stopu a tvrdý strop nad tím, čeho všeho se může dotknout. Block se na tenhle vzorec podíval a rozhodl, že agent by prostě měl být členem místnosti.

Ta myšlenka je Buzz, open-source workspace od Block, Inc., který už přilákal zhruba 18 000 hvězdiček na GitHubu. Ve Buzzu lidé a AI agenti sdílejí stejné kanály, podepisují své akce stejným typem kryptografického klíče a končí ve stejném prohledávatelném logu. Je napsaný v Rustu a licencovaný pod Apache 2.0. Strávil jsem čas čtením architekturální dokumentace repozitáře, abyste to nemuseli dělat vy – a designová rozhodnutí jsou zajímavější, než marketing napovídá.

Co je Block Buzz?

Buzz je self-hostovatelný workspace od Block, Inc., kde lidé a AI agenti sdílejí stejné kanály. Běží na Nostr relayi, takže každá zpráva, reakce, patch kódu, schválení i krok workflow je jedna podepsaná událost v jediném, prohledávatelném, proti manipulaci zabezpečeném logu. Je open source pod Apache 2.0, napsaný v Rustu, a relay provozujete sami.

Hlavní poznatky:

• Agenti jsou plnohodnotní členové s vlastními klíči a auditní stopou, ne boti přišroubovaní z boku.
• Všechno (chat, patche, CI, schvalování) je jedna podepsaná Nostr událost v jediném prohledávatelném logu.
• Agenti se připojují přes ACP a MCP, takže Goose, Codex a Claude Code fungují hned po rozbalení.
• Self-hosted a open source (Apache 2.0), s poctivým veřejným seznamem toho, co ještě není hotové.

Fráze, na které projekt staví, zní „komunikační platforma s hive mind". Zní to honosně, ale každodenní realita je jednodušší: působí to jako týmový workspace. Kanály, vlákna, přímé zprávy, canvas, hlasové huddly, vyhledávání. Zvrat je v tom, co je pod povrchem. Každá akce je podepsaná událost Nostru a autorem té události může být člověk nebo proces. Stejný tvar, stejný model identity, stejná auditní stopa v obou případech.

Pokud srovnáváte agent frameworky jako LangGraph, CrewAI a OpenAI Agents SDK, Buzz je úplně jiná vrstva. Tamty jsou knihovny, které vkládáte do kódu, aby orchestrují uvažování agenta. Buzz je místnost, kde agent a váš tým mluví, předávají si práci a zanechávají záznam. Doplňují se, nekonkurují si.

Proč „agenti jako členové" mění model

Model botů má strukturální problém: agent je host. Udělíte mu příznaky oprávnění, operuje přes úzké API a když se něco pokazí, srovnáváte dvě oddělené historie – chat týmu a logy bota.

Buzz to obrací. Agent dostane vlastní pár klíčů, vlastní členství v kanálech a vlastní auditní stopu. Agenta přidáte do kanálu stejně, jako přidáte člověka. Projekt popisuje vymezení jako „by identity, not by permission flags" – tedy podle identity, ne podle příznaků oprávnění – což je stejný způsob, jakým byste vymezili lidského kolegu. V některých místnostech mu věříte a v jiných ne.

Jakmile je agent členem, dostane stejné možnosti jako všichni ostatní. Může otevírat repozitáře, posílat patche, reviewovat kód, spouštět workflow, upravovat canvasy, orchestratovat další agenty, vytvářet kanály a skočit do hlasových huddlů. README popisuje tři scénáře, které to zkonkrétní:

• Paměť incidentů. Jsou dvě ráno, zeptáte se „už jsme tahle chybu viděli?" a agent, který sleduje kanál, vytáhne půl roku historie, postne vlákna a hlavní příčiny a nabídne, že vytočí toho, kdo dodal poslední opravu. Celá výměna zůstane v kanálu jako důkaz.
• Větev jako místnost. Otevřete feature větev a objeví se kanál. Patche přistávají jako události, CI postuje výsledky, agent udělá první review a rozhodnutí o mergi žije ve stejné místnosti jako důkazy, které ho odůvodňují.
• Release, který se napíše sám. Workflow se spustí na tag, agent napíše návrh release notes z mergnutých PR, postne ho k lidskému review, dostane palec nahoru a shipne. Každý krok podepsaný, každý krok prohledávatelný.

Společným jmenovatelem je, že konverzace, kód i rozhodnutí žijí na jednom místě místo sedmi záložek, které předstírají, že o sobě vědí.

Jak se agenti skutečně připojují: ACP a MCP

Tady se inženýrství stává čistým. Buzz se dodává se dvěma malými binárkami pro agenty a ty o sobě záměrně nevědí.

buzz-agent je ACP agent. Mluví Agent Client Protocol přes stdio, volá LLM a používá MCP nástroje. Běží až osm souběžných sessions, každou s vlastními MCP servery, historií a kontextem. Když se kontext session zaplní, zrekapituluje vlastní historii a pokračuje dál. Funguje se Zed, JetBrains nebo čímkoli jiným, co mluví ACP.

buzz-dev-mcp je MCP server. Dává každému agentovi shell a editor souborů. Procesy jsou efemerní s killováním process group na každé exit cestě, výstup je ohraničený a úpravy souborů se resolvují vůči pracovnímu adresáři. Pokud jste už stavěli s Model Context Protocol, bude vám to povědomé: je to standardní vzorec „dej agentovi ruce", jen v odolnější podobě.

Designová poznámka v repozitáři to říká bez obalu: „two binaries, two protocols, no coupling between them". Agent neví, se kterým MCP serverem mluví, a MCP server neví, který agent ho volá. Skládají se přes protokoly, ne přes importy. Praktický zisk je, že za Buzzem můžete provozovat deset agentů s různými konfiguracemi MCP, nebo vyměnit poskytovatele LLM jedinou proměnnou prostředí.

Protože buzz-acp přemosťuje relay @mentions na podprocesy agentů, můžete ho namířit na Goose, Codex nebo Claude Code. Pokud už provozujete coding agenty na pozadí, Buzz jim dává sdílenou místnost, kde operovat, místo tiché headless smyčky. A pokud chcete přinést vlastní nástroje, postavení MCP serveru je podporovaná cesta, se spoustou hotových MCP serverů, ze kterých můžete vyjít.

Pod kapotou: Architektura

Buzz je Rust monorepo a jediná nejdůležitější skutečnost je tahle: relay je jediný zdroj pravdy. Žádný peer-to-peer gossip a žádná replikace. Klienti se připojují k jednomu relayi přes WebSocket a relay řeší autentizaci, ověřuje podpisy, persistuje události, rozesílá je odběratelům, indexuje je pro vyhledávání a spouští automatizaci.

Všechno je událost Nostr NIP-01. Každá událost má šest polí: id (SHA-256 serializované události), pubkey, celé číslo kind, tagy, obsah a Schnorrův podpis. Číslo kind je jediný dispatch přepínač. Chcete novou funkci? Definujte nové číslo kind. Existující klienti nevidí nic a nic se jim nerozbije. Kódová báze definuje 81 kindů, přičemž vlastní Buzz kindy žijí v rozsahu 40 000–49 999.

Podpůrný stack je záměrně nudný – v tom nejlepším smyslu:

Postgres drží události a provozuje fulltextové vyhledávání. Redis řeší pub/sub fan-out, přítomnost a psaní. S3-kompatibilní objektové úložiště (lokálně MinIO) drží média přes protokol Blossom.

Bezpečnostní model je místo, kde jsem přestal skenovat. Každá událost má před uložením ověřený Schnorrův podpis a SHA-256 ID. NIP-42 auth používá toleranci časového razítka ±60 sekund, aby zablokoval replay útoky, a auth události se nikdy neukládají ani nelogují. Auditní log je skutečný hash chain: SHA-256 každého záznamu pokrývá všechna pole včetně předchozího hashe, takže manipulace s jedním záznamem rozbije všechny záznamy po něm. Odchozí webhooky dostávají SSRF ochranu, která kontroluje privátní IP rozsahy. A členství v kanálu je jediná přístupová brána, vynucovaná při každé operaci, přičemž handler subskripcí kontroluje přístup ještě předtím, než subskripci zaregistruje – takže nevzniká žádné race-condition okénko pro úniky z privátních kanálů.

Pokud vyhodnocujete, jak nasadit agentic AI na infrastruktuře, kterou kontrolujete, tahle část stojí za přečtení dvakrát.

Co dnes funguje (a co ne)

Projekt je o svém stavu nezvykle upřímný a myslím, že ta upřímnost je nejsilnějším signálem seriózní kódové báze. Tady je aktuální stav přímo z repozitáře:

Teď ta část, kterou většina produktových příspěvků přeskakuje. Architektonický dokument vyjmenovává ověřené mezery, ne ambice:

• Rate limiting se zatím nevynucuje. Trait RateLimiter existuje a čtyři úrovně jsou navržené (human, agent-standard, agent-elevated, agent-platform), ale jediná implementace je testovací stub.
• Schvalovací brány nejsou zapojené end-to-end. Executor umí pozastavit běh, ale workflow, které narazí na schvalovací bránu, se aktuálně označí jako failed.
• Některé akce workflow jsou stubnuté. send_dm a set_channel_topic vrací „not implemented", takže běh, který na ně dojde, selže.
• Nahrávání huddlů a publikování per-track není postavené. Hlasové místnosti a životní cyklus join/leave fungují; nahrávání má rezervované kindy událostí, ale žádného producenta.
• Žádná sqlx offline query cache. Dotazy běží za runtime místo validace při kompilaci.

Nic z toho není diskvalifikující pro self-hosted nástroj, který vyhodnocujete, ale říká vám přesně, kde jsou hrany. Pokud potřebujete vyhodnocovat agenty v produkci s tvrdými garancemi, berte sloupce 💭 a 🚧 jako nosná varování.

Jak začít s Buzzem

Existují tři cesty, podle toho, kdo jste.

Chcete to jen vyzkoušet? Stáhněte si zabalený build z nejnovějšího release: macOS (.dmg), Linux (.AppImage nebo .deb) nebo Windows (.exe). Ve výchozím stavu se připojuje na ws://localhost:3000, takže pořád budete chtít mít spuštěný relay.

Chcete buildovat ze zdroje? Potřebujete Docker a buď Hermit, nebo Rust 1.88+, Node 24+, pnpm 10+ a just. Pak:

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

Relay přistane na ws://localhost:3000 a desktopová aplikace vyskočí. Pro nasazení na single-node VPS místo lokálního dev stacku existuje produkční Compose bundle pod deploy/compose/ s Postgresem, Redisem, MinIO a volitelným Caddy pro TLS.

Přinášíte agenta? Nastavte BUZZ_PRIVATE_KEY a použijte buzz-cli, který je JSON dovnitř a JSON ven, navržený přímo pro LLM tool cally. To je ten šev, kde se připojují vaše agent workflow.

Kdo by měl Buzz provozovat?

Buzz je pro týmy, které chtějí jeden substrát místo hromady lepícího kódu. Pokud je váš současný setup chat plus forge plus boti plus CI dashboardy plus release nástroje plus vyhledávací index a už vás nebaví, že o sobě nevědí, tohle je sázka, kterou Buzz dělá: jedna komunita, jeden model identity, jeden log událostí.

Skvěle sedí:

• Self-hostérům, kteří chtějí svou agentovou komunikaci na infrastruktuře, kterou vlastní, s auditní stopou, kterou si můžou ověřit.
• Platformovým inženýrům, kteří vyhodnocují agent-first workflow, kde agenti triagují bugy, provádějí review a píšou drafty releasů jako členové, ne jako skripty.
• Vyhodnocovačům open source, kteří si to chtějí přečíst celé za jedno odpoledne. Agentová plocha jsou dva craty bez couplingu, záměrně dost malé na audit.

Ještě není pro lidi, kteří chtějí hotový SaaS se vším v ceně, který můžou zítra předat netechnickému týmu. Schvalovací brány, rate limiting a mobilní klienti pořád přistávají. Buzz vám to říká otevřeně – a přesně proto bych mu důvěřoval s opatrným pilotem.

Formulace, ke které se pořád vracím, je v README: „Agenti jsou součástí místnosti, ne strašidelné cron joby." Pokud jste někdy debugovali bota ve dvě ráno bez tušení, co udělal nebo proč, už víte, proč na tom záleží.

FAQ

Je Buzz zdarma a open source?

Ano. Buzz je open source pod licencí Apache 2.0 a staví ho Block, Inc. Relay si hostujete sami, takže za software není žádný poplatek za uživatele. Vaše náklady jsou vaše vlastní infrastruktura: server na relay, Postgres, Redis a objektové úložiště. Zdroj, issues i roadmap jsou veřejné na GitHubu v block/buzz.

Jak se Buzz liší od Slacku s boty?

Ve Slacku je agent druhořadý bot s oddělenou identitou a auditní stopou, vymezený příznaky oprávnění. Ve Buzzu je agent plnohodnotný člen s vlastním párem klíčů, členstvím v kanálech a stejnými možnostmi jako člověk: otevírat repozitáře, posílat patche, spouštět workflow, účastnit se huddlů. Všechno přistává v jednom podepsaném, prohledávatelném logu událostí.

Co jsou ACP a MCP?

ACP je Agent Client Protocol, stdio rozhraní, které buzz-agent používá ke komunikaci s LLM klientem jako Zed. MCP je Model Context Protocol, rozhraní, které buzz-dev-mcp používá k tomu, aby agentovi dal shell a editor souborů. Ty dvě binárky o sobě nevědí; skládají se přes protokoly, takže můžete agenty a nástrojové servery volně míchat.

Používá Buzz blockchain?

Ne, a README je v tom přímé: „Žádný blockchain. Podepsané události jsou užitečné i bez toho, aby si každý kupoval pamětní minci." Buzz používá kryptografické podpisy Nostru a hash-chain auditní log jako důkaz proti manipulaci, ale není tu žádný token, žádný řetězec a žádný konsenzus mechanismus. Dostanete ověřitelnou historii bez režie navíc.

Můžu používat vlastní AI agenty, jako Goose, Codex nebo Claude Code?

Ano. Harness buzz-acp spawnuje podprocesy AI agentů a přemosťuje na ně relay @mentions přes ACP. Goose, Codex a Claude Code podporuje hned po rozbalení, provozuje pool jednoho až 32 procesů agentů a agenta po crashi restartuje. Pro vlastní nástroje připojíte svůj MCP server.

Je Buzz production-ready?

Zčásti. Relay, kanály, vyhledávání, auditní log, desktopová aplikace a agent CLI fungují dnes. Ale rate limiting se nevynucuje, schvalovací brány nejsou zapojené end-to-end a mobilní klienti jsou pořád ve vývoji. Pro self-hosted pilot s týmem, který toleruje ostré hrany, je připravený k vyzkoušení. Pro nasazení kritické z pohledu compliance počkejte, až přistanou body 🚧.

O autorovi

Mert Batur je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a voice/SDR pipeline pro B2B klienty. Píše o LLM nástrojích, které tým Techsy skutečně používá v produkci. Spojte se s ním na LinkedInu.