Die kurze Antwort
Am 21. Juli 2026 hat Block KI-Agenten etwas gegeben, das ihnen bislang meist fehlte: eine überprüfbare eigene Identität. Buzz ist ein kostenloser, quelloffener (Apache-2.0) Workspace, der Team-Chat, Code-Hosting und automatisierte Workflows zusammenführt und Agenten als vollwertige Mitglieder behandelt statt als angeflanschte Bots. Auf Basis des Nostr-Protokolls gibt er jedem Agenten ein kryptografisches Schlüsselpaar und fügt eine zweite Signatur hinzu, die diesen Agenten an einen menschlichen Eigentümer bindet — ein Nachweis, den keiner von beiden allein fälschen könnte.
Das Produkt selbst ist noch jung (Version 0.4.22 zum Start, mit noch reifender Git-Integration), das Übernehmenswerte ist also die Idee, nicht zwingend das Werkzeug. Je mehr autonome Coding-Agenten ein Team betreibt, desto mehr wird die Frage, welcher Agent was in wessen Auftrag getan hat, von einer netten Zusatzinfo zur Prüfpflicht.
Was hat Block tatsächlich veröffentlicht?
Block, das Payments- und Fintech-Unternehmen von Jack Dorsey, hat Buzz als kostenlosen, quelloffenen Workspace unter der Apache-2.0-Lizenz veröffentlicht, selbst gehostet über github.com/block/buzz oder als gehostete Version unter buzz.xyz. An der Oberfläche wirkt er vertraut — Kanäle, Threads, Direktnachrichten, Sprache, Medien-Sharing, Code-Repositories und automatisierte Workflows an einem Ort — und Block sagt ausdrücklich, man ziele auf Unternehmen, deren Arbeit heute zwischen Slack und GitHub aufgeteilt ist. Der Unterschied liegt darin, wer als Mitglied zählt: Neben Menschen treten KI-Agenten mit eigenen Konten und Berechtigungen bei und können wie eine Kollegin posten, Code prüfen und Automatisierungen anstoßen.
Das Wesentliche steckt darunter, in der Identität. Buzz basiert auf Nostr, dem dezentralen Messaging-Protokoll, das jedem Agenten ein kryptografisches Schlüsselpaar gibt, das von der Plattform selbst unabhängig ist. Eine zweite Signatur bindet jeden Agenten an seinen menschlichen Eigentümer und erzeugt, was Block einen »kryptografischen Nachweis nennt, den weder der Mensch noch der Agent allein erzeugen könnte«. Patches, Continuous-Integration-Ergebnisse und Review-Kommentare bleiben neben der Diskussion in einem einzigen Audit-Datensatz erhalten — die Handlung eines Agenten ist damit kein anonymes Ereignis in einem Log, sondern ein signiertes, zurechenbares. Das ist die Identitäts- und Herkunftsschicht, die die meisten Teams, die Claude Code und ähnliche Agenten verdrahten, bisher von Hand improvisiert haben.
Auf der Modellebene ist Buzz bewusst offen gehalten. Es ist modell- und agentenagnostisch, bindet Agenten über das Agent Client Protocol — einen offenen Standard — ein und unterstützt Anthropics Claude Code, OpenAIs Codex und Blocks eigenes goose-Framework von Anfang an. Bradley Axen, bei Block für KI-Fähigkeiten verantwortlich, brachte es auf den Punkt: »Jedes Unternehmen wird einen Ort brauchen, an dem Menschen und Agenten zusammenarbeiten. Die Frage ist, ob dieser Ort proprietär oder offen ist.«
Warum zählt Agenten-Identität gerade jetzt?
Weil Teams aufgehört haben, einen Agenten zu betreiben, und angefangen haben, viele zu betreiben — und die Werkzeuge darunter für Menschen gebaut wurden. In Slack und GitHub taucht ein KI-Agent typischerweise als App, als Bot oder, schlimmer, als geteiltes Dienstkonto auf — ein einzelner Zugang, den mehrere Automatisierungen still weiterverwenden. Das funktioniert, bis etwas schiefgeht. Wenn ein Agent eine fehlerhafte Änderung pusht, das falsche System kontaktiert oder einen riskanten Merge genehmigt, ist »welcher Agent, für wen handelnd« genau die Frage, die sich aus einem geteilten Token nicht sauber beantworten lässt.
Jedem Agenten seine eigene kryptografische Identität zu geben, kehrt das um. Blocks eigener Coding-Agent BuilderBot bewältigt Berichten zufolge in der Größenordnung von 200.000 Operationen pro Tag und steht für einen erheblichen Anteil der Produktionscode-Änderungen des Unternehmens (wie von The New Stack berichtet) — die Art von Volumen, bei der anonyme Automatisierung zur operativen und Compliance-Haftung wird. Identität plus signierter Datensatz bedeutet, dass jede Agenten-Handlung im Nachhinein zurechenbar ist: wer sie ausgeführt hat, in wessen Auftrag und was sie berührt hat. Das ist der Unterschied zwischen »die KI war's« und einem Ereignis, das man tatsächlich prüfen kann.
Das offene, protokollbasierte Design zählt aus demselben Grund. Indem Buzz die Identität in ein Nostr-Schlüsselpaar statt in die Plattform legt, verhindert es, dass die Identität eines Agenten an den umzäunten Garten eines einzelnen Anbieters gebunden ist — im Einklang mit dem breiteren Branchentrend zu offenen Agenten-Standards. Ob Buzz selbst sich durchsetzt oder nicht, die Richtung ist klar: Autonome Akteure brauchen portable, überprüfbare Identitäten, keine geliehenen menschlichen.
Was unterschätzen Teams?
Das Erste ist die Reife. Buzz startete mit Version 0.4.22, die Git-Integration wurde als noch frühes Stadium beschrieben. Ein vielversprechendes Identitätsmodell macht eine junge Plattform nicht bereit, morgen Ihren primären Chat und Ihr Code-Hosting zu tragen. Die kluge Lesart ist, Buzz als frühe Referenzimplementierung einer übernehmenswerten Idee zu behandeln und es an internen Aufgaben mit geringer Schadenswirkung zu pilotieren, bevor man Workflows darauf setzt.
Das Zweite ist, dass Identität nicht Autorisierung ist. Zu wissen, welcher Agent etwas getan hat, ist notwendig, aber nicht hinreichend; Sie müssen weiterhin entscheiden, was jeder Agent tun darf. Ein kryptografischer Nachweis sagt Ihnen, dass ein Agent nach main gemergt oder ein System angeschrieben hat — er hält ihn nicht davon ab. Eng gefasste Berechtigungen, Review-Gates für alles, was ausgeliefert wird, und ein benannter menschlicher Eigentümer pro Agent sind die Kontrollen, die Herkunftsnachweis in Sicherheit verwandeln. Buzz gibt Agenten eigene Konten und Berechtigungen; sie gut zu nutzen bleibt eine Entwurfsentscheidung, keine Voreinstellung.
Das Dritte ist Governance und Datenkontrolle. Selbst-Hosting gibt Ihnen die volle Kontrolle über die Daten; die von Block gehostete Option ist bequem, legt die Aktivität Ihrer Agenten aber auf fremde Infrastruktur — eine reale Überlegung für regulierte FinTech- und Gesundheitsteams unter DSGVO und EU-KI-Verordnung. Für die DACH-Region kommt hinzu: In Deutschland gibt das BSI mit seinen Empfehlungen zur KI-Sicherheit den Rahmen vor, und BaFin-regulierte Banken müssen die Kontrolle über automatisierte Systeme nachweisen können. Für diese Teams ist der Nutzen echt: Ein signierter Datensatz darüber, wer oder was ein System verändert hat, ist genau der Nachweis, nach dem Prüferinnen und Prüfer fragen. Aber er hilft nur, wenn Bereitstellung, Aufbewahrung und Zugriffsmodell bewusst entschieden und nicht aus einer Voreinstellung geerbt werden.
Was es für Teams in den USA & der DACH-Region bedeutet
Die produktive Lesart dieser Veröffentlichung ist nicht »Wechselt zu Buzz«. Sie lautet: Agenten-Identität und Herkunftsnachweis werden zum Standard, und jetzt ist der Zeitpunkt, sie in die eigenen Agenten-Workflows einzubauen — egal, auf welches Werkzeug Sie sich am Ende festlegen. Wenn Sie bereits Coding-Agenten über Claude Code, Codex oder goose betreiben, ist die praktische Konsequenz, sie nicht länger über geteilte Zugänge handeln zu lassen, sondern jedem eine eigene, zurechenbare Identität mit benanntem Eigentümer und dauerhaftem Nachweis seiner Handlungen zu geben.
Für regulierte Teams ist der Compliance-Aspekt die scharfe Kante. Unter der EU-KI-Verordnung und der DSGVO ist ein autonomes System, das auf Daten einwirkt oder Änderungen vornimmt, etwas, wofür Sie Rechenschaft ablegen können müssen — wer es autorisiert hat, was es getan hat, ob der Datensatz aufbewahrt wurde. Ein signierter, agentenbezogener Audit-Trail ist der Unterschied zwischen dem Nachweis von Kontrolle und der Hoffnung, dass Ihre Logs genügen. Das ist eine Governance-Anforderung, die Sie eingebaut haben wollen, bevor Sie Agenten skalieren, und nicht nach einem Vorfall rekonstruieren.
Es gibt auch einen strategischen Punkt für Engineering-Verantwortliche. Wenn der Workspace zur Steuerungsebene für Agenten wird, verstärkt sich der Wert für Teams, die Zugriff, Identität und Herkunftsnachweis bereits als Engineering-Vermögenswerte behandeln: Ihre Menschen und Ihre Agenten laufen auf demselben klaren Berechtigungsmodell. Teams mit improvisierten Bot-Tokens und unklarer Eigentümerschaft erhalten stattdessen autonome Aktionen, die niemand vollständig zurechnen kann — und das in Maschinengeschwindigkeit. Offenheit hilft hier: Ein offenes Protokoll und ein offener Standard bedeuten, dass Sie ein Muster übernehmen, keinen Lock-in.
Wie Sie dieses Quartal handeln
Sie müssen nicht zu Buzz migrieren, um von dem zu profitieren, was es signalisiert. Hier ist die auslieferbare Fassung.
- Geben Sie jedem Agenten eine eigene Identität. Betreiben Sie Coding- oder Workflow-Agenten nicht länger über geteilte Dienstkonten; geben Sie jedem einen eigenen Zugang, den Sie zurechnen können.
- Benennen Sie pro Agent einen menschlichen Eigentümer. Machen Sie jemanden dafür verantwortlich, was jeder Agent tun darf und welche Auswirkungen er verursacht.
- Führen Sie einen signierten, dauerhaften Datensatz. Bewahren Sie auf, welcher Agent welche Änderung vorgenommen hat — samt Patch, CI-Ergebnis und Review, nicht nur als flüchtiges Chat-Log.
- Trennen Sie Identität von Autorisierung. Fassen Sie die Berechtigungen jedes Agenten eng und sichern Sie alles Kunden- oder Produktionsnahe hinter menschlicher Prüfung ab.
- Pilotieren Sie Buzz an interner Arbeit. Wenn das Modell reizt, testen Sie es selbst gehostet an risikoarmen Aufgaben, bevor Sie ihm den primären Chat oder das Code-Hosting anvertrauen.
- Entscheiden Sie die Datenkontrolle vorab. Wählen Sie für regulierte Workloads bewusst zwischen selbst gehostet und gehostet — mit definierter Aufbewahrung und definiertem Zugriff für Prüfer.
Gut genutzt ist ein Agenten-Workspace mit echter Identität eine sinnvolle Konsolidierung: zurechenbare Aktionen, klare Eigentümerschaft, ein regierter Ort, an dem eine Flotte von Agenten beobachtet wird. Nachlässig genutzt bedeutet mehr Autonomie auf geliehenen Zugängen nur schnellere Fehler, die niemand nachverfolgen kann. Der Unterschied ist das Identitäts- und Herkunftsmodell, auf dem Sie bestehen — in welchem Werkzeug auch immer Sie es betreiben.
Häufig gestellte Fragen
Was hat Block am 21. Juli 2026 veröffentlicht?
Block hat Buzz veröffentlicht, einen kostenlosen, quelloffenen (Apache-2.0) Workspace, in dem Mitarbeitende und KI-Agenten Kanäle, Code-Repositories und Workflows teilen. Er läuft auf dem Nostr-Protokoll, gibt jedem Agenten ein eigenes kryptografisches Schlüsselpaar, und eine zweite Signatur bindet jeden Agenten an einen menschlichen Eigentümer. Buzz ist selbst gehostet über github.com/block/buzz oder gehostet unter buzz.xyz verfügbar und modellagnostisch — es unterstützt Claude Code, OpenAIs Codex und Blocks goose-Framework.
Warum ist eine eigene Identität für einen KI-Agenten wichtig?
Wenn mehrere Agenten über Chat, Code und CI hinweg handeln, müssen Teams belegen können, welcher Agent was in wessen Auftrag getan hat. Buzz gibt jedem Agenten ein Schlüsselpaar unabhängig von der Plattform und fügt eine zweite Signatur hinzu, die ihn mit einem menschlichen Eigentümer verknüpft — ein Nachweis, den keiner allein fälschen könnte — und bewahrt Patches, CI-Ergebnisse und Reviews in einem Audit-Datensatz. Für regulierte Teams verwandelt das »die KI war's« in ein zurechenbares, prüfbares Ereignis.
Ist Buzz an ein einzelnes KI-Modell oder einen Anbieter gebunden?
Nein. Buzz ist modell- und agentenagnostisch. Agenten werden über das Agent Client Protocol eingebunden, einen offenen Standard, und es unterstützt Anthropics Claude Code, OpenAIs Codex und Blocks goose. Weil die Identität in einem Nostr-Schlüsselpaar statt in der Plattform liegt, ist die Identität eines Agenten nicht an Buzz gebunden. Offenheit ist das Verkaufsargument: Block formuliert die Frage so, ob der Ort, an dem Menschen und Agenten zusammenarbeiten, proprietär oder offen ist.
Sollten Teams Buzz jetzt produktiv einsetzen?
Behandeln Sie es als frühen Standard zum Pilotieren, nicht als fertige Plattform. Zum Start war es Version 0.4.22 mit noch reifender Git-Integration, testen Sie es also zuerst an internen, risikoarmen Aufgaben. Die Idee, die man unabhängig vom Werkzeug übernehmen sollte, ist Agenten-Identität und Herkunftsnachweis: Geben Sie jedem autonomen Akteur eine überprüfbare Identität, einen benannten Eigentümer und einen Audit-Trail. Beginnen Sie dort, lassen Sie Menschen alles prüfen, was ausgeliefert wird, und bewerten Sie Buzz gegen Ihren aktuellen Stack, bevor Sie sich festlegen.
Wie unterscheidet sich Buzz von Slack plus GitHub?
Slack und GitHub wurden für Menschen gebaut; Agenten werden als Apps oder Bots ohne erstklassige Identität angeflanscht. Buzz führt Chat, Code-Hosting und Workflows zusammen und behandelt Agenten als Mitglieder mit eigenen kryptografischen Konten und Berechtigungen, nicht als geteilte Zugänge. Das macht die Nachrichten, Reviews und Automatisierungen jedes Agenten einzeln zurechenbar und prüfbar — die Lücke, die Block für über Slack und GitHub verteilte Teams adressiert.
Quellen
Block — Introducing Buzz: where humans and agents work together (Primärquelle), 21. Juli 2026
SiliconANGLE — Block launches Buzz, an open-source workspace for humans and AI agents, 21. Juli 2026
The New Stack — Block built a Slack for AI agents, and gave each one its own passport, 21. Juli 2026