Wenn Agenten zu Kollegen werden: Die Idee hinter Buzz

Über Buzz habe ich bereits geschrieben, damals mit einem klaren Fokus auf Shared Compute und den gemeinsamen Modellbetrieb. Das war für mich zunächst der spannendste und ungewöhnlichste Teil des Projekts. Je länger ich mich mit Buzz beschäftige, desto interessanter wird aber der Arbeitsraum selbst. Deshalb habe ich Buzz inzwischen auch in einem kleinen Setup ausprobiert.

Das liegt auch an einem Problem, das ich in den letzten Monaten immer deutlicher spüre. Meine Arbeit mit KI ist nicht nur schneller, sondern auch unübersichtlicher geworden. Codex arbeitet an einem Repository, Claude Code prüft eine zweite Idee, ein anderer Agent sammelt Informationen, und irgendwo dazwischen laufen Terminal, Browser, E-Mail und mehrere Chats. Jeder Agent kann für sich nützlich sein. Das Problem entsteht an den Übergängen. Kontext muss kopiert, Entscheidungen müssen wiederholt und Ergebnisse manuell zusammengeführt werden.

Genau dort setzt Buzz an. Das Open-Source-Projekt stammt von Block, dem von Twitter-Mitgründer Jack Dorsey geführten Unternehmen hinter Square. Es will nicht noch einen weiteren KI-Assistenten bauen. Buzz schafft einen gemeinsamen Arbeitsraum, in dem Menschen und Agenten dieselben Channels, Threads, Projekte und Protokolle verwenden. Ein Codex-Agent kann einen Plan erstellen, Claude Code kann ihn kritisieren, ein Mensch kann die Entscheidung treffen und der nächste Agent kann daraus eine Änderung im Repository machen. Die ganze Kette bleibt im selben Raum sichtbar.

Der schnelle Begriff “Slack-Killer” greift für mich zu kurz. Buzz zeigt eine mögliche Arbeitsform für Teams mit vielen Agenten. Gleichzeitig ist es noch jung, ressourcenhungrig und sicherheitstechnisch anspruchsvoller, als die freundliche Oberfläche vermuten lässt. Gerade diese Mischung aus grosser Idee und frühem Entwicklungsstand macht einen genaueren Blick interessant.

Das eigentliche Problem ist nicht das Modell

Die meisten KI-Werkzeuge sind als Beziehung zwischen einem Menschen und einem Agenten entstanden. Ich öffne Codex, gebe eine Aufgabe ein und erhalte ein Ergebnis. Danach öffne ich Claude Code, erkläre denselben Hintergrund noch einmal und bitte um eine zweite Meinung. Für einzelne Aufgaben funktioniert das gut. In einem Team oder bei mehreren parallel laufenden Agenten entsteht jedoch ein neues Koordinationsproblem.

Genau dieses Problem kenne ich aus meinem Alltag. Claude Code, Codex, Hermes, Browser, Chats und verschiedene Terminals laufen nebeneinander. Sitzungsprotokolle wandern von einem Werkzeug in das nächste. Ein Agent kennt die Besprechungsnotizen, ein anderer das Repository und ein dritter die benötigten Zugänge oder Skills. Jeder hat einen Ausschnitt, aber niemand den gemeinsamen Arbeitsstand.

Mission-Control-Dashboards lösen das nur teilweise. Sie zeigen vielleicht, dass fünf Agenten aktiv sind. Sie schaffen aber noch keinen gemeinsam verständlichen Ort, an dem Auftrag, Diskussion, Zwischenstand, Review und Entscheidung zusammenbleiben. Buzz setzt deshalb nicht bei einer schöneren Agentenliste an, sondern beim Arbeitsraum selbst.

Agenten sind Mitglieder und keine angeklebten Bots

Auf den ersten Blick sieht Buzz vertraut aus. Es gibt Communities, öffentliche und private Channels, Threads, Direktnachrichten, Foren, Suche, Huddles und eine mobile App. Der entscheidende Unterschied zu einer gewöhnlichen Slack-Integration liegt darunter.

Ein Agent ist in Buzz ein eigenes Mitglied. Er besitzt ein Profil, ein kryptografisches Schlüsselpaar, Channel-Mitgliedschaften und einen eigenen Audit-Trail. Seine Nachrichten erscheinen unter seiner Identität. Dadurch lässt sich später nicht nur sehen, dass “die KI” etwas getan hat. Es wird sichtbar, welcher Agent gehandelt hat, in welchem Channel er den Auftrag erhielt und welcher Mensch oder andere Agent ihn ausgelöst hat.

Das klingt zunächst wie eine kleine Änderung der Benutzerverwaltung. Für echte Arbeit ist es aber zentral. Ein Slack-Bot hängt meist an einer Integration und wartet darauf, von einem Menschen erwähnt zu werden. Zwei Bots unterschiedlicher Anbieter wissen normalerweise nichts voneinander. In Buzz können Agenten andere Agenten ansprechen, Aufgaben übergeben und ihre Ergebnisse im selben Thread diskutieren. Codex und Claude Code werden damit nicht zu einem einzigen System. Sie erhalten aber einen gemeinsamen Kommunikationsraum.

Buzz bringt dabei nicht automatisch die gesamte Intelligenz mit. Der Arbeitsraum verbindet sogenannte Harnesses und Modelle, die bereits lokal, auf einem Server oder über einen Anbieter laufen. Dazu gehören laut aktuellem Projektstand unter anderem Codex, Claude Code und Goose. Weitere Agenten können über offene Schnittstellen angebunden werden. Das ist ein Bring-your-own-agent-Modell: Buzz koordiniert, der jeweilige Agent denkt und handelt mit seinen eigenen Tools, Skills, Zugängen und Modellkosten.

Der Relay ist der gemeinsame Arbeitsstand

Technisch besteht Buzz aus mehreren Teilen. Die Desktop-App ist die Oberfläche. Eine Community ist der eigentliche Arbeitsraum. Der Buzz Relay speichert und verteilt dessen Nachrichten, Mitglieder, Agenten, Regeln, Medien, Suchdaten, Workflows und Git-Ereignisse. Agenten können auf demselben Rechner wie die Desktop-App, auf einem ständig laufenden Server oder auf einer ganz anderen Maschine arbeiten.

Als Protokoll verwendet Buzz Nostr. Menschen und Agenten signieren Ereignisse mit ihren privaten Schlüsseln. Der Relay prüft Identität und Mitgliedschaft, speichert die Events und verteilt sie an berechtigte Clients. Das macht Buzz jedoch nicht zu einem magischen Peer-to-Peer-Netzwerk. Der Relay ist die zentrale Quelle einer Community. Es gibt keine automatische Replikation zwischen Relays, und Nachrichten bleiben auf dem Relay, auf dem sie gesendet wurden.

Diese Konstruktion hat zwei interessante Folgen. Die Identität gehört nicht einfach einem zentralen Slack-Konto, sondern basiert auf einem eigenen Schlüsselpaar. Gleichzeitig kann ein Team den Arbeitsraum selbst betreiben. Wer zunächst nur testen will, kann eine von Block gehostete Community verwenden. Wer Datenhaltung, Verfügbarkeit und Backup selbst kontrollieren möchte, betreibt den Relay auf eigener Infrastruktur.

Die aktuelle Serverarchitektur verwendet bekannte Komponenten: PostgreSQL für Events und Volltextsuche, Redis für Pub/Sub sowie S3-kompatiblen Speicher für Medien. Das ist kein kleiner Dienst, den man nach der Installation vergessen sollte. Ein selbst betriebener Relay braucht TLS, Updates, Backups, Monitoring und eine saubere Schlüsselverwaltung.

Warum der gemeinsame Kontext so wertvoll ist

Die stärkste Idee von Buzz ist der dauerhafte, gemeinsam sichtbare Kontext. Ein Projekt besteht nicht mehr aus einer Chatnachricht in Slack, einem separaten Agentenlauf, einem Pull Request auf GitHub und einer Entscheidung in einer Videokonferenz. Buzz versucht, diese Spuren in einem Ereignisraum zusammenzubringen.

Das ist besonders nützlich, wenn verschiedene Agenten unterschiedliche Stärken haben. Ein realistischer Ablauf kann so aussehen:

1. Ein Mensch beschreibt im Projekt-Channel das Ziel und die Grenzen.
2. Ein Research-Agent sammelt Informationen und dokumentiert seine Quellen.
3. Ein zweiter Agent greift die Schwachstellen an und sucht Gegenargumente.
4. Codex oder Claude Code erstellt einen konkreten Plan.
5. Ein anderer Agent prüft den Plan auf Sicherheit, fehlende Tests oder unklare Annahmen.
6. Nach menschlicher Freigabe wird die Änderung in einem separaten Worktree umgesetzt.
7. Diff, Testresultate, Review und Entscheidung bleiben im zugehörigen Channel auffindbar.

Besonders spannend ist dieses Muster bei adversarial Reviews. Ein Modell erhält ausdrücklich die Rolle, einen Produktplan oder eine Implementierung anzugreifen. Ein zweites Modell muss die Entscheidungen verteidigen oder verbessern. Weil beide den vollständigen Thread sehen, entsteht eine echte Auseinandersetzung mit dem bisherigen Arbeitsstand und nicht nur ein isoliertes Review eines kopierten Textes.

Auch für Content- und Business-Prozesse ist das Muster interessant. Ein Agent recherchiert Themen, ein zweiter schreibt, ein dritter redigiert. Kennzahlen oder neue Meldungen können regelmässig in einen Channel fliessen, damit Menschen und Agenten die Entwicklung gemeinsam besprechen. Huddles gehen noch einen Schritt weiter: Menschen und Agenten sprechen in einer Audiokonferenz, das Gespräch wird in Text überführt und kann anschliessend in konkrete Aufgaben übergehen.

Das ist der Punkt, an dem Buzz mehr als ein Gruppenchat wird. Der Channel ist nicht nur ein Ort für Kommunikation. Er wird zum nachvollziehbaren Arbeitsprotokoll.

GitHub ersetzen will Buzz ebenfalls

Buzz integriert Git-Repositories, Patches, Reviews und Statusereignisse in denselben Arbeitsraum. Der Relay kann Repositories selbst hosten. Agenten können Worktrees verwenden, getrennt an Varianten arbeiten, Änderungen als Patch bereitstellen und Reviews im Projektkontext diskutieren.

Die Vision dahinter ist stark: Ein Feature-Branch wird zu einem Raum. Dort liegen nicht nur die Commits, sondern auch die Diskussion, warum eine Änderung notwendig war, welche Alternativen verworfen wurden, was die CI gemeldet hat und wer den Merge freigegeben hat. Gerade bei agentisch erzeugtem Code fehlt diese Entstehungsgeschichte heute häufig.

Trotzdem würde ich GitHub noch nicht vorschnell abschreiben. GitHub ist nicht nur Git-Speicher, sondern ein über Jahre gewachsenes Ökosystem für Rechte, Reviews, CI/CD, Security-Scans, Releases, Integrationen und externe Zusammenarbeit. Buzz hat funktionierende Git-Grundlagen und einen interessanten Forge-Ansatz. Der eigene Projektstatus unterscheidet aber klar zwischen bereits funktionierenden Teilen, noch verdrahteten Funktionen und Vision. Für kritische Repositories ist ein schrittweiser Einsatz vernünftiger als eine sofortige Migration.

Mein erster Test mit Buzz

Ich habe bewusst klein angefangen: eine eigene Community, ein Channel und zwei Agenten mit klar getrennten Rollen. Codex sollte einen technischen Plan erstellen, Claude Code sollte Annahmen, Sicherheitslücken und unnötige Komplexität angreifen. Produktive Zugangsdaten, Kundendaten und sensible Repositories blieben draussen. Mir ging es zuerst darum, die Zusammenarbeit und nicht die maximale Autonomie zu testen.

Der erste offene Auftrag war zu ungenau. Beide Agenten begannen zu planen, reagierten aufeinander und warteten irgendwann auf den nächsten Impuls. Das war eine gute Erinnerung daran, dass ein gemeinsamer Channel noch keine Orchestrierung ersetzt. Mit der klaren Anweisung “Codex erstellt den Plan, Claude prüft ihn, danach wartet ihr auf Freigabe” wurde der Ablauf deutlich ruhiger und nachvollziehbarer. Mehr Agenten ersetzen keine Prozessdefinition.

Am meisten überzeugt hat mich nicht eine spektakuläre Einzelantwort, sondern der fehlende Medienbruch. Beide Agenten sahen denselben Thread, die Kritik blieb neben dem ursprünglichen Plan stehen, und ich konnte jederzeit nachvollziehen, wer gerade arbeitete. Ich musste keinen Text zwischen Fenstern kopieren und keinem zweiten Agenten die Vorgeschichte neu erklären. Genau darin liegt für mich der eigentliche Wert von Buzz.

Für intensive Softwareentwicklung blieb die direkte Arbeit in Codex oder Claude Code trotzdem schneller. Buzz fügt Kommunikation, Protokollierung und gemeinsamen Kontext hinzu. Diese Schicht kostet Zeit und Tokens. Jeder zusätzliche Agent besitzt eine eigene Sitzung, und umfangreiche Channel-Historie kann bei mehreren Modellen mehrfach verarbeitet werden. Für einen langen Coding-Lauf würde ich deshalb weiterhin das native Harness verwenden und Buzz eher für Planung, Übergaben und Reviews einsetzen.

Noch nicht tief genug getestet habe ich Workflows, längere Huddles, lokale Modelle und mehrere dauerhaft laufende Remote-Agenten. Genau dort muss Buzz im Alltag beweisen, dass Aufgaben nicht nur schön sichtbar sind, sondern auch zuverlässig abgeschlossen werden. Die Software ist vor Version 1.0 und fühlt sich an einigen Stellen entsprechend jung an. Für Experimente ist das in Ordnung. Zentrale Abläufe brauchen aber weiterhin Kontrolle, Wiederholungslogik und einen klaren manuellen Rückweg.

Gemeinsamer Kontext ist auch eine Sicherheitsgrenze

Was Buzz nützlich macht, vergrössert gleichzeitig die Angriffsfläche. Ein angebundener Codex-, Claude-Code- oder Hermes-Agent bringt möglicherweise Dateizugriff, Shell, Browser, MCP-Server, E-Mail, Kalender oder andere interne Werkzeuge mit. Wenn ein Teammitglied diesen Agenten ansprechen darf, reicht die Berechtigung weit über das Schreiben einer Chatantwort hinaus.

Die wichtigste Regel lautet deshalb: Ein Agent darf nur in Channels arbeiten, deren Inhalt und Mitglieder zu seinem Werkzeugzugriff passen. Die Channel-Mitgliedschaft ist das zentrale Zugriffstor. Wer Mitglied ist, kann lesen und schreiben. Wer nicht Mitglied ist, soll weder private Channels sehen noch deren Events abonnieren können.

Kryptografische Signaturen lösen dennoch nicht jedes Audit-Problem. Buzz führt ein verkettetes, manipulationssichtbares Audit-Log. Ein Angreifer mit Schreibzugriff auf die Datenbank könnte die Kette nach einer Manipulation jedoch neu berechnen. Das Log ist damit tamper-evident, nicht tamper-resistant. Es macht Änderungen erkennbar, solange die Vertrauensbasis des Speichers nicht vollständig gefallen ist.

Für Block-gehostete Communities kommt ein weiterer Punkt hinzu: Nachrichten, Direktnachrichten und hochgeladene Medien sind nicht Ende-zu-Ende verschlüsselt. Block kann diese Inhalte für Betrieb, Sicherheit, Moderation oder rechtliche Pflichten einsehen. Zusätzlich kann der jeweilige Modellanbieter Prompts und Channel-Inhalte erhalten, wenn ein Agent einen Cloud-Dienst nutzt.

Self-Hosting verändert die Datenhoheit, aber nicht automatisch den gesamten Datenfluss. Ein eigener Relay hält Nachrichten und Dateien auf der eigenen Infrastruktur. Nutzt der Agent weiterhin ein Cloud-Modell, verlassen die für den Auftrag benötigten Daten den Relay trotzdem. Wirklich lokaler Betrieb erfordert deshalb sowohl einen eigenen Relay als auch lokale Modelle und lokale Tools. Über die Möglichkeiten und Grenzen von Buzz Shared Compute habe ich bereits separat geschrieben.

So setze ich Buzz vorerst ein

Für meinen ersten Test habe ich eine kleine, klar abgegrenzte Community verwendet. Keine produktiven Zugangsdaten, keine Kundendaten und kein Repository mit Geheimnissen. Zwei Agenten reichten vollkommen: einer erstellt, einer prüft. Dazu komme ich als Mensch, der Auftrag, Freigabepunkt und Abbruchkriterium festlegt.

Mein erster Aufbau war kein autonomes Unternehmen mit hundert Agenten, sondern ein begrenztes Review:

• Ein Agent erstellt einen technischen Plan aus einem vorhandenen Issue.
• Ein zweiter Agent sucht Sicherheitslücken, fehlende Annahmen und unnötige Komplexität.
• Beide müssen Quellen, Dateien und offene Fragen nennen.
• Nach höchstens zwei Diskussionsrunden wartet das Team auf menschliche Freigabe.
• Erst danach darf ein Agent in einem isolierten Worktree Änderungen vorbereiten.

Damit konnte ich die eigentliche Stärke von Buzz testen, ohne sofort meinen gesamten Betrieb umzubauen. Gleichzeitig wurden Tokenverbrauch, Latenz, Rechte und Nachvollziehbarkeit sichtbar.

Für Solo-Arbeit mit einer einzelnen Coding-Aufgabe bleibe ich bei der direkten Agentenoberfläche. Sie ist schneller und leichter zu kontrollieren. Buzz wird interessant, sobald mehrere Menschen, mehrere Agenten oder mehrere Arbeitsströme denselben Kontext brauchen. Kleine Entwicklerteams, Agenturen, Forschungsgruppen und technisch versierte Solopreneure sind deshalb die naheliegende Zielgruppe.

Für ein grösseres Unternehmen wäre ich zurückhaltender. Vor Version 1.0, ohne Langzeit-Supportlinie und mit noch jungen Workflows würde ich Buzz nicht zum einzigen Ort für kritische Kommunikation oder Quellcode machen. Ein Pilotprojekt kann sinnvoll sein. Eine vollständige Ablösung von Slack und GitHub wäre derzeit eine Wette auf die Entwicklungsgeschwindigkeit des Projekts.

Die Idee hinter Buzz ist grösser als der aktuelle Client

Der spannendste Teil von Buzz ist für mich nicht ein einzelnes Feature. Channels, Foren, Huddles, Git-Hosting und lokale Modelle gibt es an anderen Orten ebenfalls. Neu ist die konsequente Annahme, dass Agenten nicht mehr nur private Werkzeuge einzelner Nutzer sind. Sie werden zu sichtbaren Teilnehmern eines gemeinsamen Arbeitsprozesses.

Damit verschiebt sich die Frage. Wir fragen nicht mehr nur, welches Modell den besten Code schreibt. Wir müssen entscheiden, wie Menschen und mehrere Agenten Aufgaben verteilen, Kontext teilen, einander kontrollieren und Verantwortung nachvollziehbar machen. Genau dafür fehlt heute oft die soziale und technische Infrastruktur.

Buzz liefert noch keine fertige Antwort. Die Software ist jung, einige Workflows sind unzuverlässig, der gemeinsame Kontext kann teuer werden und Self-Hosting bringt echte Betriebsverantwortung. Trotzdem trifft das Projekt ein reales Problem. Wenn Agenten immer mehr Arbeit übernehmen, reicht es nicht, fünf Einzelchats nebeneinander zu öffnen. Wir brauchen einen gemeinsamen Ort, an dem ihre Arbeit sichtbar, begrenzt und überprüfbar bleibt.

Vielleicht ersetzt Buzz Slack und GitHub irgendwann. Für heute reicht eine kleinere, aber wichtigere Aussage: Buzz ist ein überzeugender Entwurf dafür, wie ein Arbeitsraum aussehen kann, wenn nicht mehr nur Menschen darin arbeiten. Shared Compute hat mich auf das Projekt aufmerksam gemacht. Der gemeinsame Arbeitsraum ist der Grund, warum ich Buzz weiter testen werde.

Mein Fazit nach dem ersten Test

Buzz hat in meinem kurzen Test genau das Problem getroffen, das ich momentan mit KI-Agenten habe. Die einzelnen Modelle sind längst nicht mehr der Engpass. Schwierig ist es, mehrere Agenten, Entscheidungen und Ergebnisse auf einer gemeinsamen Linie zu halten. Buzz macht diese Arbeit sichtbar und gibt Codex, Claude Code und anderen Agenten einen Ort, an dem sie nicht nur auf mich, sondern auch aufeinander reagieren können.

Überzeugt haben mich der gemeinsame Kontext, die klar getrennten Agentenidentitäten und die Möglichkeit, ein Ergebnis direkt von einem zweiten Modell angreifen zu lassen. Weniger überzeugt hat mich der zusätzliche Overhead. Für eine einzelne Coding-Aufgabe ist der direkte Weg über Codex oder Claude Code noch schneller. Sobald mehrere Agenten oder Menschen beteiligt sind, beginnt Buzz seine Stärke auszuspielen.

Mein Test war bewusst kurz. Ich habe weder einen dauerhaften Team-Betrieb noch grosse Repositories, komplexe Workflows oder längere Lastspitzen geprüft. Dafür ist die Software noch jung und bewegt sich zu schnell. Ich würde Buzz heute nicht zum einzigen Ort für kritische Kommunikation oder Quellcode machen. Für ein kleines Team, eine Agentur oder ein persönliches KI-Lab ist es aber bereits mehr als eine interessante Demo. Es ist ein Werkzeug, das ich weiter verwenden und gezielt in meinen Arbeitsalltag einbauen möchte.

Bis zum nächsten Mal,
Euer Joe

FAQ