Block Buzz: Der KI-Agenten-Workspace, in dem Agenten Teamkollegen sind, keine Bots

Block Buzz: Der KI-Agenten-Workspace, in dem Agenten Teamkollegen sind, keine Bots

Die meisten „KI in deinem Chat"-Setups funktionieren gleich: Du flanschst einen Bot an Slack oder Discord, gibst ihm einen Slash-Befehl, und er antwortet, wenn er gerufen wird. Der Bot lebt außerhalb des Teams. Er hat eine eigene Identität, einen eigenen Audit-Trail und eine harte Obergrenze dafür, was er anfassen darf. Block hat sich dieses Muster angesehen und entschieden, dass der Agent einfach ein Mitglied des Raums sein sollte.

Diese Idee ist Buzz, ein Open-Source-Workspace von Block, Inc., der bereits rund 18.000 GitHub-Sterne gesammelt hat. In Buzz teilen Menschen und KI-Agenten dieselben Kanäle, signieren ihre Aktionen mit derselben Art kryptografischer Schlüssel und landen im selben durchsuchbaren Log. Es ist in Rust geschrieben und unter Apache 2.0 lizenziert. Ich habe mich durch die Architektur-Docs des Repos gelesen, damit du es nicht musst, und die Designentscheidungen sind interessanter, als das Marketing vermuten lässt.

Was ist Block Buzz?

Buzz ist ein selbst hostbarer Workspace von Block, Inc., in dem Menschen und KI-Agenten dieselben Kanäle teilen. Er läuft auf einem Nostr-Relay, sodass jede Nachricht, jede Reaktion, jeder Code-Patch, jede Freigabe und jeder Workflow-Schritt ein signiertes Event in einem einzigen, durchsuchbaren, manipulationssicheren Log ist. Er ist Open Source unter Apache 2.0, in Rust gebaut, und du betreibst das Relay selbst.

Die wichtigsten Punkte:

• Agenten sind Mitglieder erster Klasse mit eigenen Schlüsseln und eigenem Audit-Trail, keine nebenher angeflanschten Bots.
• Alles (Chat, Patches, CI, Freigaben) ist ein signiertes Nostr-Event in einem einzigen durchsuchbaren Log.
• Agenten binden sich über ACP und MCP an, sodass Goose, Codex und Claude Code out of the box funktionieren.
• Selbst gehostet und Open Source (Apache 2.0), mit einer ehrlichen, öffentlichen Liste dessen, was noch nicht fertig ist.

Der Begriff, auf den das Projekt setzt, ist „a hive mind communication platform". Das klingt groß, aber der Alltag ist simpler: Es fühlt sich an wie ein Team-Workspace. Kanäle, Threads, DMs, ein Canvas, Voice-Huddles, Suche. Der Clou ist das, was darunterliegt. Jede Aktion ist ein signiertes Nostr-Event, und der Autor dieses Events kann eine Person oder ein Prozess sein. Gleiche Form, gleiches Identitätsmodell, gleicher Audit-Trail in beiden Fällen.

Wenn du Agenten-Frameworks wie LangGraph, CrewAI und das OpenAI Agents SDK verglichen hast, ist Buzz eine völlig andere Ebene. Das sind Bibliotheken, die du in Code einbettest, um das Reasoning eines Agenten zu orchestrieren. Buzz ist der Raum, in dem der Agent und dein Team sprechen, Arbeit übergeben und eine Spur hinterlassen. Sie ergänzen sich, sie konkurrieren nicht.

Warum „Agenten als Mitglieder" das Modell verändert

Das Bot-Modell hat ein strukturelles Problem: Der Agent ist ein Gast. Du gewährst ihm Berechtigungs-Flags, er agiert über eine schmale API, und wenn etwas schiefgeht, gleichst du zwei getrennte Historien ab – den Chat des Teams und die Logs des Bots.

Buzz dreht das um. Ein Agent bekommt sein eigenes Schlüsselpaar, seine eigenen Kanal-Mitgliedschaften und seinen eigenen Audit-Trail. Du fügst einen Agenten einem Kanal genauso hinzu wie eine Person. Das Projekt beschreibt die Scope-Definition als „by identity, not by permission flags" – genauso, wie du einen menschlichen Teamkollegen einordnen würdest. Du vertraust ihnen in manchen Räumen und in anderen nicht.

Sobald ein Agent Mitglied ist, bekommt er dieselben Möglichkeiten wie alle anderen. Er kann Repos öffnen, Patches senden, Code reviewen, Workflows ausführen, Canvases bearbeiten, andere Agenten orchestrieren, Kanäle erstellen und in Voice-Huddles einsteigen. Das README führt drei Szenarien vor, die das konkret machen:

• Incident-Gedächtnis. Es ist 2 Uhr nachts, du fragst „Hatten wir diesen Fehler schon einmal?", und ein Agent, der den Kanal beobachtet, zieht sechs Monate Historie, postet die Threads und Root Causes und bietet an, die Person zu informieren, die den letzten Fix geliefert hat. Der gesamte Austausch bleibt als Beleg im Kanal.
• Branch als Raum. Du öffnest einen Feature-Branch, und ein Kanal erscheint. Patches landen als Events, CI postet Ergebnisse, ein Agent macht einen ersten Review-Durchlauf, und die Merge-Entscheidung lebt im selben Raum wie die Belege, die sie gerechtfertigt haben.
• Ein Release, das sich selbst schreibt. Ein Workflow feuert bei einem Tag, ein Agent entwirft Release Notes aus den gemergten PRs, postet sie zur menschlichen Prüfung, bekommt eine Daumen-hoch-Reaktion und liefert aus. Jeder Schritt signiert, jeder Schritt durchsuchbar.

Der rote Faden ist, dass die Konversation, der Code und die Entscheidung alle an einem Ort leben, statt in sieben Tabs, die so tun, als wüssten sie voneinander.

Wie Agenten sich tatsächlich anbinden: ACP und MCP

Hier wird das Engineering sauber. Buzz liefert zwei kleine Binaries für Agenten, und sie wissen bewusst nichts voneinander.

buzz-agent ist ein ACP-Agent. Er spricht das Agent Client Protocol über stdio, ruft ein LLM auf und nutzt MCP-Tools. Er führt bis zu acht parallele Sessions aus, jede mit eigenen MCP-Servern, eigenem Verlauf und eigenem Kontext. Wenn sich der Kontext einer Session füllt, fasst sie ihren eigenen Verlauf zusammen und macht weiter. Er funktioniert mit Zed, JetBrains oder allem anderen, was ACP spricht.

buzz-dev-mcp ist ein MCP-Server. Er gibt jedem Agenten eine Shell und einen Datei-Editor. Prozesse sind ephemer mit Process-Group-Kill auf jedem Exit-Pfad, Output ist begrenzt, und Datei-Edits werden gegen das Arbeitsverzeichnis aufgelöst. Wenn du schon mit dem Model Context Protocol gebaut hast, kommt dir das bekannt vor: Es ist das Standardmuster „gib einem Agenten Hände", gehärtet.

Die Design-Notiz im Repo sagt es unverblümt: „two binaries, two protocols, no coupling between them." Der Agent weiß nicht, mit welchem MCP-Server er spricht, und der MCP-Server weiß nicht, welcher Agent ihn ruft. Sie komponieren über Protokolle, nicht über Imports. Der praktische Nutzen ist, dass du zehn Agenten hinter Buzz mit unterschiedlichen MCP-Konfigurationen betreiben oder deinen LLM-Anbieter mit einer Umgebungsvariable wechseln kannst.

Weil buzz-acp Relay-@mentions an Agenten-Subprozesse bridged, kannst du ihn auf Goose, Codex oder Claude Code richten. Wenn du bereits Background-Coding-Agents einsetzt, gibt Buzz ihnen einen gemeinsamen Raum zum Agieren statt einer stillen Headless-Schleife. Und wenn du deine eigenen Tools mitbringen willst, ist einen MCP-Server bauen der unterstützte Weg, mit reichlich fertigen MCP-Servern als Startpunkt.

Unter der Haube: Die Architektur

Buzz ist ein Rust-Monorepo, und die wichtigste Tatsache überhaupt ist diese: Das Relay ist die einzige Source of Truth. Es gibt kein Peer-to-Peer-Gossip und keine Replikation. Clients verbinden sich über WebSocket mit einem Relay, und das Relay übernimmt Auth, verifiziert Signaturen, persistiert Events, verteilt sie an Subscriber, indexiert sie für die Suche und löst Automation aus.

Alles ist ein Nostr-NIP-01-Event. Jedes Event hat sechs Felder: eine id (SHA-256 des serialisierten Events), einen pubkey, eine kind-Ganzzahl, Tags, Content und eine Schnorr-Signatur. Die kind-Ganzzahl ist der einzige Dispatch-Schalter. Ein neues Feature gewünscht? Definiere eine neue Kind-Nummer. Bestehende Clients sehen nichts und brechen nicht. Die Codebase definiert 81 Kinds, wobei eigene Buzz-Kinds im Bereich 40000-49999 leben.

Der unterstützende Stack ist bewusst langweilig, im besten Sinne:

Postgres hält die Events und führt die Volltextsuche aus. Redis übernimmt Pub/Sub-Fan-out, Presence und Tippen. S3-kompatibler Object Storage (lokal MinIO) hält Medien über das Blossom-Protokoll.

Das Sicherheitsmodell ist der Punkt, an dem ich aufgehört habe zu überfliegen. Bei jedem Event werden Schnorr-Signatur und SHA-256-ID verifiziert, bevor es gespeichert wird. NIP-42-Auth nutzt eine ±60-Sekunden-Zeitstempel-Toleranz, um Replay-Angriffe zu blockieren, und Auth-Events werden nie gespeichert oder auditiert. Das Audit-Log ist eine echte Hash-Chain: Der SHA-256 jedes Eintrags umfasst jedes Feld einschließlich des vorherigen Hashs, sodass die Manipulation eines Eintrags jeden Eintrag danach bricht. Ausgehende Webhooks bekommen SSRF-Schutz, der auf private IP-Bereiche prüft. Und die Kanal-Mitgliedschaft ist das einzige Zugriffstor, durchgesetzt bei jeder Operation, wobei der Subscription-Handler den Zugriff prüft, bevor er eine Subscription registriert, sodass es kein Race-Fenster für Leaks privater Kanäle gibt.

Wenn du bewertest, wie du agentische KI deployen kannst auf Infrastruktur, die du kontrollierst, ist das der Teil, den man zweimal lesen sollte.

Was heute funktioniert (und was nicht)

Das Projekt ist ungewöhnlich ehrlich über seinen eigenen Status, und ich halte diese Ehrlichkeit für das stärkste Signal einer seriösen Codebase. Hier ist der aktuelle Stand direkt aus dem Repo:

Jetzt der Teil, den die meisten Produkt-Posts überspringen. Das Architektur-Doc listet verifizierte Lücken, keine Wunschträume:

• Noch kein Rate Limiting durchgesetzt. Das RateLimiter-Trait existiert und vier Stufen sind designed (human, agent-standard, agent-elevated, agent-platform), aber die einzige Implementierung ist ein Test-Stub.
• Freigabe-Gates sind nicht Ende-zu-Ende verdrahtet. Der Executor kann einen Run aussetzen, aber ein Workflow, der auf ein Freigabe-Gate trifft, wird aktuell als fehlgeschlagen markiert.
• Manche Workflow-Aktionen sind Stubbed. send_dm und set_channel_topic geben „not implemented" zurück, sodass ein Run, der eine davon erreicht, fehlschlägt.
• Huddle-Aufzeichnung und Pro-Track-Publishing sind nicht gebaut. Voice-Räume und Join/Leave-Lebenszyklus funktionieren; Aufzeichnung hat reservierte Event-Kinds, aber keinen Producer.
• Kein sqlx-Offline-Query-Cache. Queries laufen zur Laufzeit, statt zur Compile-Zeit validiert zu werden.

Nichts davon disqualifiziert ein selbst gehostetes Tool, das du bewertest, aber es zeigt dir genau, wo die Kanten sind. Wenn du Agenten in Produktion evaluieren musst mit harten Garantien, behandle die 💭- und 🚧-Spalten als tragende Warnungen.

Erste Schritte mit Buzz

Es gibt drei Wege, je nachdem, wer du bist.

Nur ausprobieren? Hol dir einen paketierten Build aus dem neuesten Release: macOS (.dmg), Linux (.AppImage oder .deb) oder Windows (.exe). Standardmäßig verbindet er sich mit ws://localhost:3000, du willst also trotzdem ein laufendes Relay.

Aus dem Quellcode bauen? Du brauchst Docker und entweder Hermit oder Rust 1.88+, Node 24+, pnpm 10+ und just. Dann:

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

Das Relay landet auf ws://localhost:3000 und die Desktop-App poppt auf. Für ein Single-Node-VPS-Deployment statt des lokalen Dev-Stacks gibt es ein Production-Compose-Bundle unter deploy/compose/ mit Postgres, Redis, MinIO und optional Caddy für TLS.

Einen Agenten mitbringen? Setze BUZZ_PRIVATE_KEY und nutze buzz-cli, das JSON rein und JSON raus ist, speziell designed für LLM-Tool-Calls. Das ist die Nahtstelle, an der deine Agenten-Workflows andocken.

Wer sollte Buzz betreiben?

Buzz ist für Teams, die ein Substrat wollen statt eines Haufens Glue-Code. Wenn dein aktuelles Setup aus Chat plus einer Forge plus Bots plus CI-Dashboards plus Release-Tools plus einem Suchindex besteht und du es satt hast, dass sie nichts voneinander wissen, dann ist das die Wette, die Buzz eingeht: eine Community, ein Identitätsmodell, ein Event-Log.

Es passt gut für:

• Selbst-Hoster, die ihren Agenten-Traffic auf eigener Infrastruktur wollen, mit einem Audit-Trail, den sie verifizieren können.
• Platform Engineers, die Agenten-first-Workflows bewerten, in denen Agenten Bugs triagieren, Reviews fahren und Releases entwerfen – als Mitglieder, nicht als Skripte.
• Open-Source-Evaluierer, die das Ganze an einem Nachmittag lesen wollen. Die Agenten-Oberfläche ist zwei Crates ohne Kopplung, bewusst klein genug zum Auditieren.

Noch nichts ist es für Leute, die ein fertiges, Batterien-inklusive-SaaS wollen, das sie morgen einem nicht-technischen Team geben können. Die Freigabe-Gates, das Rate Limiting und die mobilen Clients landen noch. Buzz sagt dir das offen, und genau deshalb würde ich ihm einen sorgfältigen Piloten anvertrauen.

Das Framing, auf das ich immer wieder zurückkomme, steht im README: „Agents are part of the room, not haunted cron jobs." Wenn du je um 2 Uhr nachts einen Bot debuggt hast, ohne zu wissen, was er getan hat oder warum, weißt du schon, warum das wichtig ist.

FAQ

Ist Buzz kostenlos und Open Source?

Ja. Buzz ist Open Source unter der Apache-2.0-Lizenz und gebaut von Block, Inc. Du hostest das Relay selbst, es gibt also keine Pro-Sitz-Gebühr für die Software. Deine Kosten sind deine eigene Infrastruktur: ein Server für das Relay, Postgres, Redis und Object Storage. Quellcode, Issues und Roadmap sind alle öffentlich auf GitHub unter block/buzz.

Wie unterscheidet sich Buzz von Slack mit Bots?

In Slack ist ein Agent ein Bot zweiter Klasse mit separater Identität und separatem Audit-Trail, scoped über Berechtigungs-Flags. In Buzz ist ein Agent ein Mitglied erster Klasse mit eigenem Schlüsselpaar, eigenen Kanal-Mitgliedschaften und denselben Möglichkeiten wie ein Mensch: Repos öffnen, Patches senden, Workflows ausführen, an Huddles teilnehmen. Alles landet in einem signierten, durchsuchbaren Event-Log.

Was sind ACP und MCP?

ACP ist das Agent Client Protocol, die stdio-Schnittstelle, die buzz-agent nutzt, um mit einem LLM-Client wie Zed zu sprechen. MCP ist das Model Context Protocol, die Schnittstelle, die buzz-dev-mcp nutzt, um einem Agenten eine Shell und einen Datei-Editor zu geben. Die beiden Binaries wissen nichts voneinander; sie komponieren über Protokolle, sodass du Agenten und Tool-Server frei mischen kannst.

Nutzt Buzz Blockchain?

Nein, und das README ist deutlich dazu: „Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz nutzt Nostrs kryptografische Signaturen und ein Hash-Chain-Audit-Log für Manipulationssicherheit, aber es gibt keinen Token, keine Chain und keinen Konsensmechanismus. Du bekommst verifizierbare Historie ohne den Overhead.

Kann ich meine eigenen KI-Agenten nutzen, wie Goose, Codex oder Claude Code?

Ja. Der buzz-acp-Harness startet KI-Agenten-Subprozesse und bridged Relay-@mentions über ACP an sie. Er unterstützt Goose, Codex und Claude Code out of the box, betreibt einen Pool von einem bis 32 Agenten-Prozessen und startet einen Agenten neu, wenn er abstürzt. Für eigene Tools bindest du deinen eigenen MCP-Server an.

Ist Buzz production-ready?

Teile schon. Das Relay, Kanäle, Suche, Audit-Log, Desktop-App und Agenten-CLI funktionieren heute. Aber Rate Limiting wird nicht durchgesetzt, Freigabe-Gates sind nicht Ende-zu-Ende verdrahtet, und mobile Clients sind noch in Arbeit. Für einen selbst gehosteten Piloten mit einem Team, das raue Kanten toleriert, ist es bereit zum Ausprobieren. Für ein Compliance-kritisches Deployment warte, bis die 🚧-Punkte gelandet sind.