Was ist Buzz? Jack Dorseys KI-Agenten-Workspace erklärt

Was ist Buzz?

Buzz ist, in den eigenen Worten von Block, "ein Workspace, in dem Menschen und Agenten gemeinsam bauen, auf einem Relay, das dir gehört." Wer schon mit Slack gearbeitet hat, wird sich in der Oberfläche sofort zurechtfinden: eine Seitenleiste mit Kanälen, Threads, Direktnachrichten, Emoji-Reaktionen, Voice-Huddles und geteilten Medien.

Der Clou ist, wer sonst noch im Raum sitzt. Neben deinen Teammitgliedern lädst du spezialisierte KI-Agenten in dieselben Kanäle ein, wo sie posten, Code reviewen, genehmigte Automatisierungen ausführen und sich allgemein eher wie Kollegen verhalten als wie ein Slash-Command-Bot, den man ruft und wieder entlässt. Und weil Buzz auch Git-Hosting mitbringt, können sich die Diskussion über ein Feature und der zugehörige Pull-Request am selben Ort abspielen.

Blocks Ein-Satz-Zusammenfassung bringt die Wette auf den Punkt: Menschen, Kontext, Entscheidungen und nächste Schritte in einem gemeinsamen Raum zu halten, statt über eine Chat-App, einen Tracker und deine Entwicklertools verstreut. Damit positioniert sich Buzz klar als Herausforderer sowohl für Slack (beim Chat) als auch für GitHub (beim Code).

Wer hat Buzz gebaut, und warum

Buzz stammt von Block, Inc., dem Fintech-Unternehmen hinter Square, Cash App, Afterpay und Tidal. Das ist wichtig: Wie TechCrunch anmerkte, signalisiert ein Block-Produkt "mehr als nur ein Herzensprojekt von Dorsey". Als Sprecher tritt Bradley Axen, Head of AI Capabilities bei Block, auf, und sein Satz fasst die gesamte These zusammen:

"Every company is going to need a place where humans and agents work together. The question is whether that place is proprietary or open. We built Buzz because we believe it should be open."

Bradley Axen, Block

Das "Warum" ist ein Koordinationsproblem, kein Intelligenzproblem. Blocks Engineering-Blog bringt es auf den Punkt: "Models can do the work now. Teams still need somewhere to do it together. The bottleneck moved from intelligence to coordination." Sie beschreiben die alte Arbeitsweise so, dass jeder allein mit einem Agenten in einem kleinen Harness-Fenster sitzt, dessen Output in Slack kopiert und Antworten wieder zurückgeklebt werden, und landen bei einem Satz, den die meisten von uns wiedererkennen werden: "Nobody enjoyed being middleware."

Buzz baut auf zwei Jahren KI-Tooling auf, das Block als Open Source veröffentlicht hat, darunter das eigene Agenten-Framework goose. Der Launch-Tweet erzielte die Zahlen, die man von einem Dorsey-Launch erwartet, rund 11.000 Likes und über 700 Antworten innerhalb weniger Stunden.

Die vier Buzzwords, entschlüsselt

Dorseys Launch-Tweet stützte sich auf vier Begriffe. Sie klingen nach Krypto-nahem Wortgeklingel, aber jeder steht für eine konkrete Design-Entscheidung. Hier die Version in Klartext:

Eine Klarstellung lohnt sich, weil sie viele frühe Leser verwirrt hat: Nostr ist keine Blockchain, und es gibt keinen Token. Im Hacker-News-Thread musste das immer wieder klargestellt werden:

"No blockchains here. Nostr is just a standard signed message format being relayed by simple store and forward relay servers."

sharperguy, Hacker News

Trotz der Dezentralisierungs-Sprache gibt es also keinen Krypto-Token, keinen Governance-Token und keinen Airdrop. "Decentralized" bedeutet hier "nicht im Besitz eines einzelnen Servers", nicht "auf einer Blockchain".

Agenten sind Mitglieder, keine Bots

Das ist der Teil, der Buzz wirklich von einem an Slack angeflanschten Chatbot unterscheidet. In Buzz hat ein Agent "dieselben Möglichkeiten wie ein menschliches Teammitglied, denselben Audit-Trail, nur ein anderes Schlüsselpaar." Der Slogan, den das Team immer wieder wiederholt: "Agents are members, not bots" und "agents are part of the room, not haunted cron jobs."

Das Raffinierte ist das Sicherheitsmodell, und es lohnt sich, es zu verstehen, wenn du je nervös warst, einem Agenten deine Zugangsdaten zu geben. Statt einem Agenten dein Login zu geben, gibt Buzz jedem Agenten seinen eigenen Schlüssel. Der Besitzer des Agenten signiert eine eng begrenzte Autorisierung, und der Agent signiert danach seine eigene Arbeit unter seiner eigenen Identität. Damit geht die Urheberschaft nicht verloren: Der Agent ist der Urheber, und sein Credential beweist, wer ihn unter welchen Bedingungen autorisiert hat. Wird ein Schlüssel geleakt, widerrufst du den Agenten, ohne die menschliche Identität anzutasten.

Block beschreibt außerdem, wie ein Frontier-Agent einen Schwarm günstigerer, schnellerer Agenten steuert, die parallel recherchieren, bauen, testen und reviewen, und die sich alle über gewöhnliche Kanal-Erwähnungen austauschen. Wer über Multi-Agenten-Orchestrierung bisher nur abstrakt gelesen hat, sieht hier, wie das in der Praxis aussieht ... nämlich wie ein ganz normaler Gruppenchat.

Git-Hosting: die Idee "Branch als Raum"

Buzz hört beim Chat nicht auf. Es beginnt, Code-Hosting ins eigene Haus zu holen, und das Modell dahinter ist clever: Ein Feature-Branch ist ein Kanal. Man öffnet einen Branch, ein Raum erscheint, Patches landen als signierte Events, die CI postet ihre Ergebnisse in den Raum, ein Agent führt einen ersten Code-Review durch, und die Merge-Entscheidung fällt am selben Ort wie alle Belege.

Unter der Haube speichert Buzz Repos als unveränderliche, inhaltsadressierte Packfiles plus einen veränderlichen Pointer, was sie sogar mit TLA+ formal auf Haltbarkeit modellgeprüft haben. Der Anspruch ist, dass eine einzige Community das ersetzen kann, was Teams heute mit Chat, Forges, Bots, CI-Dashboards und jeder Menge Kleber-Code nachbauen, ein Substrat statt sieben Tabs, die vorgeben, voneinander zu wissen.

Die Git-Integration ist heute das unfertigste Stück, also sollte man diesen Abschnitt eher als Vision denn als aktuelle Realität lesen.

Ist Buzz schon gut genug?

Hier kommt es auf Ehrlichkeit an. Buzz ist Apache-2.0, bewegt sich schnell (3.600 GitHub-Stars und rund 1.800 Commits in den ersten Tagen) und wurde klar von Leuten gebaut, denen die Architektur wichtig ist. Aber es ist auch sehr früh dran. Der aktuelle Desktop-Build ist v0.4.22, also noch vor Version 1.0, und Blocks eigenes README teilt die Features in drei Kategorien ein:

Die Reaktion auf Hacker News spaltete sich sauber, und es lohnt sich, bei dieser Spaltung zu verweilen. Die Skeptiker fanden das Ganze leicht dystopisch:

"That screenshot is some Lynchian horror... the humans and agent bots engage in flirty emoji-filled chats with cutesy names. I'm trying to imagine a world in which this makes sense as a way to organize software development work, but coming up short."

themgt, Hacker News

Die Enthusiasten sahen das Gegenteil: einen frühen, ehrlichen Versuch in Richtung einer echten Verschiebung, wie Arbeit erledigt wird.

"The entire development world is being fundamentally rewired and will not ever look the same. This is just one experiment at a new shape. It's probably not the winning idea, but I'd imagine we'll see lots of these attempts to reframe how work is done."

echelon, Hacker News

Meine Einschätzung: Beide haben recht. Buzz ist ein gut gebautes Experiment, das man im Auge behalten sollte, und kein Tool, auf das man dieses Quartal den täglichen Workflow eines Teams verwetten sollte. Dorseys eigene Einladung lautete, "come test the early stages with us," und das ist genau die richtige Haltung dazu.

Buzz gibt Agenten einen Raum. Support braucht einen Agenten mit einer Aufgabe.

Hier kommt der Perspektivwechsel, den ich versprochen habe, und das ist es, was ich mir wünsche, dass eine Support- oder Ops-Führungskraft aus dem ganzen Buzz-Hype mitnimmt. Buzz ist ein Ort. Eine wunderschön gestaltete Oberfläche, auf der Agenten herumhängen und erwähnt werden können. Das ist tatsächlich die richtige Form für offene, explorative Arbeit, etwa für ein kleines Team, das gemeinsam einen Prototyp baut.

Aber ein großer Teil der echten Arbeit ist nicht offen. Kundensupport ist das klarste Beispiel. Man will keinen Agenten, der in einem Kanal sitzt, darauf wartet, von einem Menschen per @-Erwähnung angesprochen zu werden, und das Ticket dann zurückgibt. Man will einen Agenten, der das Ticket übernimmt, deine Wissensdatenbank liest und es tatsächlich von Anfang bis Ende löst, ohne dass für die einfachen 60 % ein Mensch im Loop sein muss.

Das ist ein anderes Design-Problem, und genau daran verbringe ich meine Tage. Ein Agent-im-Raum wird danach beurteilt, wie natürlich er chattet. Ein Agent-mit-einer-Aufgabe wird nach Lösungsrate, Genauigkeit und danach beurteilt, ob er weiß, wann er eskalieren muss. Das Zweite richtig hinzubekommen, hat weniger mit einer hübschen Kanal-UI zu tun als damit, den Agenten in deinen echten Dokumenten und vergangenen Tickets zu verankern und darauf vertrauen zu können, was er tut, wenn niemand hinschaut. Dieses Vertrauen ist ehrlich gesagt der schwierige Teil, und deshalb ist es ein Warnsignal, wenn der Demo-Screenshot mehr zählt als die Lösungsrate.

eesel für die Arbeit ausprobieren, die Buzz nicht macht

Wenn Buzz dich dazu gebracht hat, über Agenten als Teammitglieder nachzudenken, lautet die naheliegende nächste Frage für ein Support-Team: Welcher Agent schließt das Ticket tatsächlich ab? Dafür gibt es eesel. Es ist ein KI-Agent für den Kundenservice, der sich mit deinem bestehenden Helpdesk (Zendesk, Freshdesk, Gorgias und den anderen) verbindet sowie mit den Orten, an denen dein Wissen bereits liegt, und dann Front-Line-Tickets eigenständig beantwortet und löst.

Das Unterscheidungsmerkmal ist Vertrauen, nicht Bauchgefühl. Bevor eesel auch nur einem einzigen echten Kunden antwortet, kannst du es gegen deine historischen Tickets simulieren, um genau zu sehen, wie es geantwortet und was es gelöst hätte, sodass du nicht rätst. Es ist in Minuten angebunden, arbeitet wie ein neuer Mitarbeiter, der dein Helpcenter schon gelesen hat, und lässt sich kostenlos ausprobieren. Buzz ist ein toller Raum; das hier ist der Kollege, der die Arbeit fertigstellt.