Block Buzz: Open-Source-Workspace für KI-Agenten

Block hat mit Buzz eine Arbeitsumgebung vorgestellt, in der Beschäftigte und KI-Agenten am selben Projekt arbeiten sollen. Der erste Eindruck erinnert an Slack, GitHub und einen Workflow-Editor. Dahinter steckt aber ein anderes Modell: Gespräche, Änderungen im Code und automatisierte Schritte werden als signierte Ereignisse behandelt. Jeder Agent tritt mit einer eigenen Identität auf. Das soll sichtbar machen, wer eine Aktion ausgelöst hat und welche Rechte dafür galten.

Das Projekt ist als Developer Preview veröffentlicht. Block will Buzz selbst hostbar und unabhängig von einzelnen Modellen halten. Teams können eigene Agenten anbinden oder Werkzeuge wie Claude Code, Codex und Goose verwenden. Für Unternehmen, die mit mehreren Agenten experimentieren, ist das interessanter als ein weiterer Chatbot im Messenger: Buzz versucht, die verstreuten Spuren aus Chat, Repository, CI und Automatisierung zusammenzuführen.

Buzz bündelt Kommunikation, Code und Agenten

In Buzz gibt es Channels, Threads, Direktnachrichten, Dateien und Canvases. Hinzu kommen Git-Ereignisse, YAML-Workflows und eine Kommandozeile für Agenten. Ein Team könnte einen Channel für einen Feature-Branch anlegen, dort Entscheidungen dokumentieren, Änderungen aus dem Repository sehen und einen Agenten mit einer klar begrenzten Aufgabe beauftragen. Für viele Entwicklungsteams ist das näher an ihrem Alltag als ein allgemeiner KI-Chat.

Der Hersteller beschreibt die Plattform in seiner Ankündigung von Buzz als offenen Ort für Zusammenarbeit zwischen Menschen und Agenten. Bradley Axen, Head of AI Capabilities bei Block, formuliert den Anspruch so: „Every company is going to need a place where humans and agents work together.“ Ob dieser Ort offen oder proprietär werde, sei eine Grundsatzentscheidung.

Das klingt groß, ist aber konkret genug, um den Unterschied zu üblichen Integrationen zu erklären. Ein Bot in Slack bekommt häufig einen Token, antwortet auf einen Befehl und verschwindet wieder aus dem Prozess. Buzz behandelt den Agenten als Teilnehmer. Er kann in einem Channel arbeiten, einen Workflow ausführen und eine nachvollziehbare Aktion hinterlassen. Die Plattform ersetzt dabei nicht die Prüfung durch das Team. Sie hält fest, was passiert ist.

Diese Art der Zusammenarbeit wird auch in anderen Produkten erprobt. Bei geteilten Agentensitzungen von GitHub Copilot und Slack rückt ebenfalls der gemeinsame Projektkontext in den Vordergrund. Buzz geht weiter, weil die Agentenidentität Teil der Architektur ist und der Quellcode unter einer freien Lizenz steht.

Eigene Schlüssel statt gemeinsamer Bot-Zugänge

Der technische Schwerpunkt von Buzz liegt bei den Identitäten. Menschen und Agenten verwenden kryptografische Schlüssel. Ein Agent arbeitet damit nicht unter dem Konto einer Mitarbeiterin oder mit einem Sammelzugang, den mehrere Automationen verwenden. Seine Mitgliedschaften in Channels, seine Berechtigungen und seine Aktionen lassen sich getrennt von anderen Teilnehmern verwalten.

Das ist vor allem bei mehreren Agenten praktisch. Ein Recherche-Agent braucht keinen Schreibzugriff auf ein Repository. Ein Release-Agent darf vielleicht einen Build anstoßen, aber keine Zugangsdaten aus einem internen Channel lesen. Werden diese Rollen über einzelne Schlüssel geführt, kann das Team einen Agenten sperren oder neu konfigurieren, ohne die übrigen Zugänge anzutasten.

Im öffentlichen Buzz-Repository dokumentiert Block dieses Modell als „portable agent identity“. Die Idee dahinter: Ein Agent soll seine Identität zwischen verschiedenen Umgebungen behalten können, ohne an einen Cloud-Anbieter gebunden zu sein. Der Quellcode nennt außerdem ein Audit-Log, Channel-Mitgliedschaften und signierte Events. Damit ist zumindest technisch sichtbar, ob eine Nachricht von einem Menschen, einem Agenten oder einem Workflow kam.

Die Trennung ist kein Sicherheitsversprechen für sich. Wer einem Agenten zu viele Rechte einräumt, hat trotz sauberem Audit-Log ein Problem. Sie schafft jedoch eine sauberere Ausgangslage als ein einziger API-Schlüssel, der in mehreren Skripten und Integrationen weiterverwendet wird. Unternehmen müssen weiterhin festlegen, welche Daten ein Agent sehen darf, welche Befehle er ausführen kann und wann Menschen eine Freigabe geben.

Wie Buzz technisch arbeitet

Buzz basiert auf Nostr. Das Protokoll arbeitet mit signierten Events und Relays, die diese Events weitergeben. Block verwendet den Ansatz für Nachrichten, Reaktionen, Git-Ereignisse und Workflow-Schritte. Ein Channel ist damit nicht nur ein Gesprächsfenster. Er kann zum Protokoll eines Vorgangs werden, sofern das Team ihn auch so nutzt.

Für Agenten gibt es die Kommandozeile buzz-cli mit JSON-Ein- und -Ausgabe. Das erleichtert die Anbindung von Skripten und Agenten-Frameworks. Über buzz-acp verknüpft das Projekt Agent Client Protocol und MCP. Wer sich mit der Frage beschäftigt, wie Modelle kontrolliert auf Daten und Werkzeuge zugreifen, findet bei MCP-Servern für kontrollierten Datenzugriff die praktische Ergänzung zu diesem Architekturthema.

Im Alltag könnte das so aussehen: Ein Agent erhält einen Auftrag in einem Channel, durchsucht vorherige Incidents, verlinkt die einschlägigen Threads und schlägt einen Patch vor. Ein Mensch prüft den Vorschlag und gibt ihn frei. Die Recherche, der Patch und die Entscheidung bleiben im selben Verlauf. Ob das den Prozess wirklich verbessert, hängt von der Disziplin des Teams ab. Ohne klare Zuständigkeiten entsteht auch in Buzz nur ein weiterer, schwer durchsuchbarer Feed.

Dieses Bild wurde komplett mit KI generiertProviderHiggsfieldModellnano_banana_flashPromptPhotorealistic editorial photograph for a German technology magazine illustrating auditable AI-agent collaboration: close documentary view of a European software engineer reviewing a printed blank deployment checklist beside a secure equipment rack, another team member in soft focus, clean contemporary workspace, natural light.

Was Teams vor dem Einsatz klären müssen

Die technische Trennung von Agentenidentitäten hilft nur, wenn die Regeln dazu passen. Ein Team sollte vor dem ersten produktiven Einsatz festlegen, welche Agenten es überhaupt gibt, wer sie einrichtet und wer ihre Rechte ändert. Auch ein gut dokumentierter Schlüssel ist wertlos, wenn niemand merkt, dass ein Agent plötzlich in einem falschen Channel arbeitet oder einen ungeplanten Workflow startet.

Besonders heikel sind Agenten mit Zugriff auf Kundendaten, Quellcode oder interne Dokumente. Hier reichen Rollen wie „Research“ oder „Release“ als Bezeichnung nicht. Es braucht konkrete Grenzen: Welche Datenquellen darf der Agent lesen? Welche Systeme darf er ansprechen? Welche Aktion ist ohne menschliche Prüfung erlaubt? Und wer wird benachrichtigt, wenn er scheitert? Die Erfahrung mit schlecht geregelten digitalen Werkzeugen im Team lässt sich auf Agenten direkt übertragen: Der Schaden entsteht meist nicht durch die Software allein, sondern durch unklare Zuständigkeiten.

Buzz kann solche Entscheidungen dokumentieren, aber nicht für ein Unternehmen treffen. Das gilt auch für die Frage, wie lange Ereignisse und Gesprächsverläufe gespeichert bleiben. Ein gemeinsamer Log ist nützlich, wenn ein Incident rekonstruiert werden muss. Er kann zugleich sensible Informationen enthalten. Self-Hosting gibt Teams mehr Kontrolle, ersetzt aber kein Konzept für Aufbewahrung, Löschung und Berechtigungsprüfung.

Bei einem Test sollte der Agent daher zunächst nur in einem abgegrenzten Bereich arbeiten. Ein Beispiel: Er sammelt die Änderungen eines Release-Zyklus, verknüpft Pull Requests mit den betreffenden Diskussionen und bereitet einen Entwurf für die Release Notes vor. Ein Mensch prüft diesen Entwurf vor der Veröffentlichung. Das ist unspektakulär, liefert aber schnell ein realistisches Bild davon, ob der gemeinsame Verlauf tatsächlich hilfreich ist.

Auch die Qualität der Suche verdient einen Blick. Buzz verspricht eine Suche über Nachrichten, Patches, Workflow-Läufe und Freigaben. Das kann viel Zeit sparen, wenn Begriffe und Entscheidungen tatsächlich in den jeweiligen Channels landen. Wer wichtige Absprachen weiter in privaten Chats, E-Mails oder externen Tickets führt, erzeugt wieder Brüche. Die Plattform kann einen Prozess bündeln, aber keine konsequente Arbeitsweise erzwingen.

Vor dem Rollout gehört deshalb ein kleiner Stresstest dazu. Das Team sollte einen bewusst fehlerhaften Auftrag anlegen, eine fehlende Berechtigung simulieren und prüfen, wie verständlich die Protokolle danach sind. Das Ergebnis sollte zeigen, dass ein Agent an einer Grenze gestoppt wurde, aus welchem Grund das geschah und ob eine andere Person den Vorgang ohne Nachfragen wiederholen kann. Solche Tests sind weniger spektakulär als ein Demo-Patch, zeigen aber, ob der Ablauf im Alltag belastbar wäre.

Developer Preview mit sichtbaren Lücken

Buzz ist noch kein ausgereifter Ersatz für Slack oder Microsoft Teams. Die Produktseite von Buzz nennt das Angebot ausdrücklich Developer Preview. Im Repository sind Relay, Channels, Suche, Canvases, Medien, CLI, Git-Ereignisse und Teile des Git-Hostings als verfügbar aufgeführt. Andere Bausteine befinden sich noch im Aufbau. Dazu gehören mobile Clients, einige Huddle-Funktionen und Approval-Gates für Workflows.

Gerade diese Freigabepunkte sind für den geschäftlichen Einsatz wichtig. Sobald ein Agent mehr darf als Informationen zusammenzufassen, braucht ein Team klare Grenzen. Ein Workflow, der ein Ticket anlegt oder einen Build startet, ist überschaubar. Einer, der Code ausrollt, Daten verändert oder Kunden kontaktiert, braucht einen nachvollziehbaren Freigabeschritt. Buzz liefert dafür noch keine fertige Unternehmenslösung.

The Next Web ordnet Buzz deshalb zugleich als Slack-Herausforderer und als frühes Projekt ein. Der Artikel hebt die offene Architektur und die portable Agentenidentität hervor. Er verweist aber auch darauf, dass Git-Funktionen noch am Anfang stehen und Buzz gegen sehr etablierte Kollaborationsplattformen antritt. Diese Einschätzung passt zum aktuellen Stand: Die Idee ist klarer als die Produktreife.

Für selbst gehostete Installationen beschreibt Block einen Stack aus Relay, PostgreSQL, Redis und S3- oder MinIO-kompatiblem Objektspeicher. Das kann für Teams interessant sein, die Daten und Infrastruktur selbst betreiben wollen. Es bedeutet aber auch Betriebspflichten: Updates, Backups, Monitoring, Schlüsselrotation und Zugriffsregeln liegen dann beim eigenen Team. Open Source nimmt diese Arbeit nicht ab.

Wo ein Test sinnvoll ist

Buzz passt eher zu technischen Teams, die bereits Agenten im Entwicklungsprozess einsetzen. Ein erster Test sollte klein bleiben. Ein nicht sensibles Repository, ein eigener Test-Channel und ein Agent mit wenigen Rechten reichen aus. Denkbar sind die Aufbereitung von Release Notes, die Triage eines Bugs oder eine Recherche, deren Quellen im Thread stehen sollen.

Danach lohnt es sich, nicht nur auf die Geschwindigkeit zu schauen. Lassen sich Entscheidungen später wiederfinden? Ist klar, welcher Agent welche Aktion ausgeführt hat? Gibt es eine nachvollziehbare Freigabe, bevor ein Workflow etwas verändert? Diese Fragen sind praktischer als die übliche Debatte darüber, ob ein Agent einen Menschen „ersetzen“ könne.

Die offenen Schnittstellen machen Buzz für Teams interessant, die sich nicht dauerhaft an einen einzelnen Anbieter binden wollen. Das gilt besonders dort, wo verschiedene Modelle und Agenten nebeneinander laufen. Wer nur gelegentlich mit einem Assistenten Text zusammenfasst oder Code ergänzt, braucht die zusätzliche Infrastruktur wahrscheinlich nicht. Wer Automatisierung und Entwicklung enger verzahnt, findet hier ein Projekt, das einen echten Versuch wert ist.

Der Reiz liegt weniger in einzelnen Funktionen als in der Entscheidung, Agenten als überprüfbare Teilnehmer eines Arbeitsraums zu behandeln. Ob sich daraus ein belastbares Werkzeug entwickelt, wird sich an den noch offenen Themen zeigen: Rechteverwaltung, Freigaben, Betrieb und tägliche Nutzung durch Teams.