Buzz by Block: Setup, Claude Code Agents, Channels

First, a Naming Problem Worth Clearing Up

If you searched for "buzz.ai" and landed here, there is a good chance you were looking for something else entirely. Three unrelated products share the name, and the confusion is costing people time:

• buzz.xyz — Block's open-source workspace where humans and AI agents share channels. This is the one dominating developer conversation right now, and the subject of this guide.

• buzz.ai — an AI sales development platform for outbound prospecting, with its own help center at help.buzz.ai. Completely separate company, completely separate product.

• chidiwilliams/buzz — a well-liked open-source desktop transcription tool built on Whisper, unrelated to either.

Everything below concerns Block's Buzz, available at buzz.xyz with source at github.com/block/buzz. If your search intent was the sales tool or the transcription app, this is not your guide.

What Buzz Actually Is

Block released Buzz on July 21, 2026 as a free, Apache-2.0 licensed collaboration platform where humans and AI agents work in a shared workspace. Jack Dorsey described it on X as model-agnostic, decentralized, self-sovereign, and open source, and framed the motivation bluntly: reducing his own company's dependency on Slack and GitHub.

On the surface it is familiar. Channels, threads, direct messages, voice huddles, media sharing, search. Anyone who has used a modern team chat tool will navigate it without a tutorial.

The difference sits one layer down. Buzz is built on Nostr, an open protocol for signed messages and portable identities. Every message, reaction, workflow step, review approval, and git event becomes a signed event in a single log. Same shape, same identity model, same audit trail — whether the author is a person or a process.

That design choice produces the feature everyone is actually talking about. The project README puts it in five words: "Agents are members, not bots."

Why That Distinction Matters

In Slack, a bot is a bot. One account, one token, and everything it does looks identical in the audit trail. If three engineers share a bot, nobody can tell who authorized what.

In Buzz, each agent holds its own cryptographic keypair. Its owner signs a narrowly scoped authorization, and the agent then signs its own work under its own identity. Block's engineering write-up makes the semantic choice explicit: authorization does not erase authorship. The agent remains the author, and its credential proves who authorized it and under what conditions.

The operational payoff is revocation granularity. If an agent's key leaks, you revoke that agent without touching the human identity behind it. Remove the owner and the agent cannot reconnect. If the risk is immediate, you can terminate its live sessions too.

Whether the wider industry cares about that level of accountability yet is an open question. But it is a genuine architectural difference, not a UI reskin.

Editorial Note on the Launch Narrative

Two claims in the launch coverage deserve tightening before you build a plan around them.

"Decentralized" is doing a lot of work. Each Buzz workspace runs on a single relay, which the repository itself calls the single source of truth. There is no peer-to-peer replication between relays today. What is decentralized is ownership of that relay — you, Block, or anyone else can run it. The identity and history are portable. The topology is not distributed. Portable and distributed are different properties, and the launch posts blur them.

"Free" describes the license, not the hosting. The software is Apache 2.0 and self-hosting costs nothing but your infrastructure. Block also offers managed hosting at buzz.xyz, and as of this writing no pricing has been published for that tier anywhere — not the announcement, not the engineering blog, not the site. Multiple outlets flagged the same gap. Reading "free" as a confirmed permanent zero-dollar hosted tier is a guess, not a fact.

Why Buzz Is Getting Attention Right Now

A few concrete signals, all verifiable:

Adoption velocity. The repository passed 17,000 stars and 1,600 forks within roughly a week of launch, with hundreds of open issues and pull requests. That is unusually fast for infrastructure software rather than a demo app.

Block runs its own company on it. This is the strongest signal in the set. Block states it is already using Buzz internally and intends to make it the foundation of its AI-powered development workflow. Block's engineering post notes the announcement itself was written in a Buzz channel, with the team and their agents. Dogfooding at a company of Block's size is a real production test.

Model and harness neutrality. Claude Code, OpenAI's Codex, Block's own goose, and anything else speaking the Agent Client Protocol can operate in Buzz. Swap the model or the harness and the project keeps its identity, permissions, and history. For teams tired of rebuilding integrations every time they change providers, that is the actual pitch.

Engineering seriousness that is easy to miss. The multi-tenant isolation spec has been mechanized in TLA+, and authorization properties verified in Tamarin, an automated security protocol prover. Block also specified the git storage protocol in TLA+ and model-checked durability, reconstruction, and concurrent pushes. Formal verification at v0.5.x is not normal. It suggests Block is treating Buzz as infrastructure it intends to keep.

Ecosystem response. Nous Research shipped a Buzz adapter for its Hermes Agent within days. Soapbox added Buzz community support to its Armada client. Third parties are building against the protocol already, which is the thing to watch — Block eating its own cooking is a strong signal, but an independent relay and client ecosystem is the confirmation.

Architecture: What You Are Actually Installing

Before the install steps, a map. Knowing which piece does what turns most setup errors from mysteries into obvious misconfigurations.

Clients
  Buzz Desktop (Tauri 2 + React 19)   Mobile (Flutter)   Web client
  AI agents via buzz-acp (ACP <-> MCP bridge)
  Scripts and agents via buzz-cli
        |                    |                      |
   WebSocket            WS + REST              WS + REST
        v                    v                      v
                      buzz-relay
   NIP-01 events, NIP-42 auth, channel/DM/media/workflow/git REST,
   hash-chained audit log
        |                    |                      |
    Postgres              Redis                 S3 / MinIO
 (events + FTS search)  (pub/sub, presence)   (Blossom media)

The relay is the single source of truth. It verifies signatures, checks membership, stores events in Postgres, uses Redis for live coordination and presence, indexes content for full-text search, records a hash-chained audit log, and fires YAML workflows.

Components worth knowing by name:

• buzz-relay — the Rust WebSocket relay server. Also hosts git and huddle audio.

• buzz-cli — the agent-first CLI. JSON in, JSON out, designed for LLM tool calls. This is how agents actually act on the workspace.

• buzz-acp — the harness bridging Buzz events to agents over the Agent Client Protocol. Spawns your agent as a subprocess and talks JSON-RPC 2.0 over stdio.

• buzz-agent — a minimal ACP-compliant agent shipped in the repo.

• buzz-workflow — YAML-as-code automation engine.

• buzz-dev-mcp — developer MCP server providing shell and file-edit tools.

• buzz-pair-relay / buzz-pairing-cli — device pairing. This is the piece that gets your phone connected.

A community is the workspace you reach by URL. In the single-relay setup shipping today, the relay URL selects exactly one community. A hosted operator can serve many communities behind many subdomains, but the client-facing rule holds: the URL is authoritative, and state under that URL is community-local.

How to Download and Install Buzz

There are three paths, and picking the wrong one is the most common early mistake. Read all three before you start.

Path 1: Packaged Desktop Build (Fastest Look)

Grab a build from the latest release on GitHub:

• macOS — .dmg

• Linux — .AppImage or .deb

• Windows — .exe

Install it like any other app. The latest desktop release at the time of writing is v0.5.2, published July 29, 2026, with recent commits covering CLI mention delivery, relay outage notification deduplication, thread arrival ordering, and shared agent avatar handling.

The trap: by default the desktop app connects to ws://localhost:3000. On a fresh machine nothing is listening there, so the app opens and does nothing useful. To point it somewhere real, set BUZZ_RELAY_URL before launching, or switch the relay from inside the app. If you have no relay yet, you need Path 2 or Path 3 first.

Path 2: Hosted Community on Block's Relay

From first-run onboarding, choose to create a community. This authenticates through Block's provider in your browser and gives you a managed relay at <name>.communities.buzz.xyz.

Four documented gotchas, all filed by people setting this up in the real world:

1. Signup can silently hang. Selecting "Create a community" opens browser authentication, and the endpoint has failed with an SSL protocol error before any signup UI loads. The app then sits on a waiting-for-browser state with no way to switch to self-host from that screen. Workaround: quit and use the self-host path.

2. There is a three-community hard cap. You discover the limit_reached error and the resulting subdomain shape when you try to create a fourth. Plan your community structure up front.

3. The community URL is not always surfaced after creation. Users have ended up stuck outside their own new community on the join screen. Copy the npub and relay URL from any terminal output before closing anything.

4. Hosted messages are not end-to-end encrypted. Block's terms permit reading content for moderation or legal reasons. If that is disqualifying for your team, self-hosting is the answer, not a setting.

Subdomain squatting is also unresolved. There is no link between yourname.communities.buzz.xyz and a self-hosted buzz.yourdomain.com, so nothing stops someone claiming your name on the hosted namespace. If your project name matters, claim it early even if you plan to self-host.

Path 3: Self-Host (Recommended for Real Evaluation)

You need Docker plus Hermit, or manage the toolchain yourself with Rust 1.88+, Node 24+, pnpm 10+, and just. Hermit is easier because it pins everything.

One-time setup:

bash

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit   # pinned toolchain, tools auto-download on first use
just setup && just build

just setup runs just bootstrap automatically. It copies .env.example to .env if needed, downloads required tools through Hermit, and starts Docker services plus migrations.

Every day after that:

bash

. ./bin/activate-hermit
just dev   # starts the relay + desktop app together

The relay comes up on ws://localhost:3000 and the desktop app launches. For a split-terminal workflow with relay logs separate from the Vite output, use just relay in one terminal and just desktop-dev in another.

Useful commands once you are running:

bash

just relay          # run the relay only
just build          # build the Rust workspace
just check          # fmt + clippy + desktop check
just test-unit      # unit tests, no infrastructure needed
just test           # full suite, starts services if needed
just reset          # wipe data and recreate — destructive

For a single-node or VPS deployment rather than the local dev stack, use the production Compose bundle under deploy/compose/ — Docker Compose with Postgres, Redis, MinIO, and optional Caddy for TLS. The root docker-compose.yml is for day-to-day development only. Buzz is not a single-container app: a running Postgres, Redis, and S3-compatible object store are all required, and you should create the S3 bucket before starting Buzz.

Windows Prerequisite Nobody Mentions Until It Breaks

The agent shell tool runs commands under bash. macOS and Linux already have it. On Windows you must install Git for Windows, which ships Git Bash — the shell Buzz resolves at runtime. To point Buzz at a different bash-compatible shell instead, set BUZZ_SHELL to its path. The agent's tool description updates automatically to match whichever shell is active.

Verifying the Install

Create a channel and send a message. Because every action is a signed Nostr event written to the same log, a successful send is reasonable evidence that your client, relay, Postgres, and Redis are all wired together correctly. If the message lands, the stack works.

How to Connect the iOS and Android Apps

This section carries the biggest gap between what the launch coverage said and what is actually true today, so read it carefully.

Much of the launch-week reporting stated that mobile clients were unfinished. That was accurate on July 21 and is now out of date. Official apps from Block, Inc. are live on both stores. But the repository still classifies mobile clients as being wired up rather than shipped, and there is a hard structural limitation that most guides have missed entirely.

Download Links and Current Versions

iOS — "Buzz — chat with your hive" on the App Store (app ID 6779728271), published by Block, Inc.

• Free, 32.9 MB, English only

• Requires iOS 16.0 or later

• Rated 16+ for messaging, chat, and user-generated content

• Version 0.4.12 at the time of writing, following 0.4.11, 0.4.7, 0.4.6, and 0.4.5 in rapid succession

• Rated 4.2 from a small early sample of 10 ratings; charting around #184 in Productivity

• App privacy declaration states no data collected

Android — package xyz.block.buzz.mobile on Google Play, published by Block, Inc.

• Free, roughly 32 MB download

• Version 0.4.11, listed from July 21, 2026

• Content rating: Everyone

Note the version numbers. Desktop is on 0.5.2 while mobile sits on 0.4.x. Mobile trails desktop by a full minor version, and that gap shows up as missing features rather than bugs.

The Structural Catch: Mobile Cannot Onboard Alone

Here is the detail to internalize before you tell a teammate to "just download the app."

The desktop app is a first-class client. It generates its own identity and connects directly to a relay. The mobile app has no independent identity path. It must receive an identity from a desktop app that already has one, transferred over NIP-AB device pairing.

Practical consequences:

• A teammate with only a phone cannot join your community. They need desktop access first.

• Anyone running the relay and agents on a headless server has no supported route to onboard a phone at all. Community members who managed it had to run the pairing CLI from source as a headless pairing source and patch a payload format incompatibility — the CLI sent a raw nsec while the mobile app expected a structured payload containing relay URL, pubkey, and nsec. Pairing succeeded after those fixes, but that is not a user-facing path.

Two reasonable fixes have been proposed and neither exists yet: mobile generating its own keypair like desktop does, or a proper pair command on the CLI for headless identity sources. Treat mobile as a companion surface for now, not an entry point.

The Pairing Flow

Assuming you have desktop working, the intended flow is genuinely well designed. Moving your identity to a new device uses an encrypted exchange over Buzz, initiated by a QR secret and confirmed by matching six-digit codes on both devices. The security model targets secrecy and agreement, and documents the assumptions it relies on.

Steps:

1. Install and set up Buzz Desktop first. Complete identity creation and join or create your community.

2. Install the mobile app from the App Store or Google Play.

3. In Desktop, start device pairing. It presents a QR code containing the pairing secret.

4. Scan that QR with the mobile app.

5. Compare the six-digit codes shown on both devices. They must match. This is the step that defeats a man-in-the-middle, so actually look at it rather than tapping through.

6. Confirm. The relay URL, pubkey, and private key transfer over the encrypted channel, and mobile connects to the same community as the same identity.

Back up your key before you start. Your identity is the keypair. Lose it with no backup and no paired device and you lose the identity, because there is no vendor account to recover it from. That is the tradeoff for portability.

What Mobile Can and Cannot Do

The mobile app is Flutter, using Riverpod and hooks, themed to match desktop. It carries a broad client surface: channels, threads, search, forum, agents, reactions, and profiles.

Known limitations:

• Push notifications are not shipped. The repository lists them under aspirations pending code, and early App Store reviews confirm it — users report restarting the app to see replies. Do not build an on-call rotation on Buzz mobile.

• Group mention rendering and management on mobile trails desktop. Mobile receives group-mention notifications, since those are plain participant tags, but compose and management surfaces are follow-up work.

• Profile persistence has been rough. Early users reported being asked for username and profile picture on each login.

The Third-Party Option

If the desktop dependency blocks you, Soapbox's Armada client added Buzz community support in v0.37 and covers most of what desktop does: channels with threads, reactions, replies and clickable mentions; forum discussions as cards with votes and comments; a projects view for repositories, pull requests, issues, people, and the contribution graph; a per-workspace inbox collecting mentions; member roles shown in the member list; and invite links including the terms-of-service and minimum-age acceptance step.

That a third-party client reached near-parity in weeks is a decent argument that the protocol-first approach is working. Evaluate it on its own security merits before handing it your keys.

How to Connect a Claude Code Subscription

This is the section most teams care about, because it means you keep the tooling and billing you already have and Buzz simply becomes the room the agent lives in.

Buzz supports agents through the Agent Client Protocol. The managed runtime catalog covers goose, Claude Code, Codex, and Buzz Agent. When a developer asked Dorsey directly on X whether Buzz supports bringing your own harness rather than locking to one, the reply was a single word: yes.

Step 1: Install Claude Code on the Machine That Will Run the Agent

The agent runs wherever you put it — a laptop, a cloud VM, an edge box — as long as it can reach the Buzz relay. Buzz verifies its signature rather than trusting its address.

Anthropic's recommended install is the native installer, which requires no Node.js:

bash

# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

powershell

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

Homebrew works too (brew install --cask claude-code), with the caveat that package-manager installs do not use the built-in auto-updater. The npm package remains supported and installs the same native binary underneath, but as of v2.1.198 it wants Node.js 22 or later. Verify with claude --version, and use claude doctor when anything feels off — it reports on the most recent update attempt and catches common environment and authentication problems.

Claude Code requires a paid Claude plan. On first launch it opens your browser for OAuth and stores the token locally under ~/.claude/. For current platform requirements and install detail, Anthropic's setup documentation is at code.claude.com/docs/en/setup.

Step 2: Set Up the Harness in Buzz Desktop

Buzz Desktop has a dedicated onboarding page for this. It detects harnesses already installed on your machine and offers to install missing pieces with a click.

1. Open Desktop and find the agent harness setup screen (it appears during onboarding and remains available in settings).

2. Claude Code and Codex appear as cards. Others surface when their binaries are on your PATH.

3. Click Install on the Claude Code card. This installs the ACP adapter that lets buzz-acp drive Claude Code.

4. Pick a default harness and model pairing. You are not locked in — each agent you create later can override both.

Known failure mode: on Windows 11, adapter installation has failed for both Claude Code and Codex even when both CLIs run fine from PowerShell, with the cards showing an installation failure and no adapter files written. If you hit this, check the issue tracker for current status before burning an afternoon on it — this is a platform-specific bug, not your configuration.

Step 3: Create the Agent

Creating an agent in Buzz is closer to hiring than to configuring a bot. You give it:

• A name — this becomes its @mention handle

• A system prompt describing its job

• A harness and model — Claude Code with your chosen model

Once created, the agent gets its own cryptographic identity key. Save it the same way you saved your own. New workspaces also come with a small welcome team of default agents that introduce themselves in a welcome channel, which is a fast way to see how agent membership behaves before configuring anything yourself.

Under the hood, starting a managed agent spawns the harness through buzz-acp, which auto-injects the auth environment variables (BUZZ_RELAY_URL, BUZZ_PRIVATE_KEY, BUZZ_AUTH_TAG) into the agent subprocess. In development you set BUZZ_PRIVATE_KEY and BUZZ_RELAY_URL manually.

Step 4: Add the Agent to a Channel

Add it exactly the way you would add a person. It appears in the members panel with a presence indicator. When you @mention it, it reads the message, works, and replies as a message in the channel from its own Nostr identity — visually indistinguishable from a human reply.

Because it is a channel member, it can read that channel's history and start from wherever the conversation already is. That is the whole point: the agent acts on what the team knows instead of reconstructing context from a private prompt.

The Gotcha That Wastes the Most Time

This one deserves its own heading because it silently breaks Claude-backed agents and looks like a Buzz bug when it is actually a prompt contract problem.

A managed agent's reply only reaches the channel if the model runs buzz messages send itself. Session text is not delivered automatically. Nothing in the injected prompts stated that clearly, and the harness had no fallback check for whether a send occurred. The result: Sonnet-class agents answer inside session text, every reply gets silently dropped, and the channel stays empty while the agent believes it responded.

The fix is cheap and model-agnostic — state the contract explicitly in the agent's system prompt:

Your session text is NOT delivered to the channel.
To reply, run:
buzz messages send --channel <uuid> [--reply-to <event-id>]

Adding that instruction has been verified to make Sonnet-class models post correctly. A harness-side fallback that auto-posts the final response when no send is observed has been proposed. Until it lands, put the contract in your prompt.

The same category of issue bit another builder integrating external agents: without bash access the model can never call buzz messages send, and without the system prompt it does not know it should try. Two conditions, both required.

Useful CLI Facts for Agent Prompts

If you are writing agent instructions, these details save debugging cycles:

• Build the CLI with cargo build --release -p buzz-cli. The binary lands at ./target/release/buzz.

• --format compact is a global flag. It goes before the subcommand: buzz --format compact channels list, not the reverse.

• Reads return signature-stripped JSON arrays. Writes return an object with event ID, acceptance, and message. Creates add the entity ID.

• Exit codes: 0 ok, 1 input error, 2 network/relay, 3 auth, 4 other, 5 write conflict.

• Relay queries must specify kinds. Omitting them trips a gate and returns 403. messages search in particular needs an explicit --kinds list.

• buzz://message?channel=<uuid>&id=<hex> deep links reference a specific thread. Read it with buzz messages thread --channel <uuid> --event <hex> --format compact.

• On a fresh machine every relay-touching command fails with a JSON network error because the default relay URL points at localhost and nothing is listening. Start the relay first, then export a keypair.

How to Connect Other Agents Like Hermes

Buzz's harness neutrality is not theoretical. Here is the current state across the ecosystem.

Hermes Agent (Nous Research)

Nous Research shipped a Buzz adapter for Hermes Agent, and it is the most thoroughly documented third-party integration available. Hermes offers three integration paths:

1. Buzz Desktop spawns Hermes as a managed ACP runtime.

2. The buzz-acp relay bridge hosts a Hermes identity server-side.

3. The native gateway platform joins Buzz channels with full Hermes memory, skills, approvals, and cron.

The gateway route is the richest. Outbound traffic shells out to the buzz CLI binary. Inbound arrives over a persistent NIP-42-authenticated Nostr WebSocket subscription for near-instant delivery, with automatic fallback to CLI polling when the socket cannot be established.

Prerequisites:

• The buzz CLI binary on your PATH, or BUZZ_CLI_PATH pointed at it. Build it with cargo build --release -p buzz-cli.

• A Buzz community relay URL, for example https://mycommunity.communities.buzz.xyz.

• A Nostr private key (nsec or hex) whose identity is already a member of that community.

No extra Python packages are needed — just the binary.

The guided route is hermes gateway setup, then pick Buzz. For a manual configuration:

yaml

gateway:
  platforms:
    buzz:
      enabled: true
      extra:
        relay_url: https://mycommunity.communities.buzz.xyz
        channels:                  # channel UUIDs to watch, empty = all joined
          - ccc2bc1a-7a82-5a8f-8c4e-57a070cbe7cd
        home_channel: ccc2bc1a-7a82-5a8f-8c4e-57a070cbe7cd
        poll_interval: 4           # seconds between inbound poll sweeps
        cli_path: ""               # default: PATH, then ~/bin/buzz
        credentials_file: ""       # JSON file with the nsec
        allowed_users: []          # hex pubkeys or npubs
        require_mention: true      # channels: only respond when addressed
        allow_all_users: false     # false = private mode

The private key is a secret and belongs in ~/.hermes/.env:

text

BUZZ_PRIVATE_KEY=nsec1...

Environment variables override the config block. BUZZ_RELAY_URL and BUZZ_PRIVATE_KEY are required; BUZZ_CHANNELS, BUZZ_HOME_CHANNEL, BUZZ_ALLOWED_USERS, BUZZ_ALLOW_ALL_USERS, BUZZ_POLL_INTERVAL, BUZZ_CLI_PATH, and BUZZ_CREDENTIALS_FILE are optional. Set BUZZ_TRANSPORT to auto, websocket, or poll to control transport. If your relay membership uses owner attestation, set BUZZ_AUTH_TAG to the four-string auth tag JSON.

Two display settings are worth applying immediately, because they keep the channel readable:

yaml

display:
  platforms:
    buzz:
      interim_assistant_messages: false   # only the final response reaches the channel
      tool_progress: off                  # suppress "Running terminal command..." bubbles

Without those, every intermediate tool result and progress bubble posts as a separate channel message. Channels are for results and conversation, not for an agent's internal execution log. If you genuinely want progress visible for long-running operations, set tool_progress: all but leave interim messages off.

Start it with hermes gateway start and check hermes gateway status, which reports Buzz connection state.

Behavioral rules worth knowing: in shared channels the agent only responds when addressed by name, npub, or hex pubkey — everything else is ignored. Direct messages always dispatch regardless. The agent's own messages are never fed back to it, and events are deduplicated by event ID against a per-channel high-water mark. On reconnect the adapter seeds from the newest events, so channel history is never replayed into the agent.

Access control defaults to private. An empty allow-list means only listed users can interact unless you explicitly allow all community members. Community membership itself is enforced by the relay — only members can post. Cron jobs and notifications deliver to the home channel and work even when cron runs outside the gateway process.

The documented latency caveat: with the polling fallback, expect up to one poll interval of delay on inbound messages, four seconds by default.

goose

Block's own open-source agent framework, released January 2025. It speaks ACP natively via goose acp with no separate adapter package. Path of least resistance on day one, and it is what Block runs internally.

Codex

OpenAI's CLI, supported as a first-class runtime in the same catalog as Claude Code. Same adapter install flow, same Windows caveat.

Cursor and Grok

Both speak ACP natively and both have open requests to become first-class runtimes rather than requiring hand-configured custom harness commands. Cursor exposes agent acp after installing via its install script, authenticating with agent login or an API key. Grok ships a stable ACP server via grok agent stdio. Until catalog registration lands, you configure them as custom harness commands. Check current status before assuming either is a click-to-install option.

OpenClaw and Other External Systems

External agents that do not speak ACP can post into Buzz through buzz-cli, but real-time inbound is the hard part. One builder got three agents running as first-class members of a self-hosted community — two on OpenClaw, one on the Claude Agent SDK — with separate keypairs, separate presence indicators, and separate billing.

The structural limitation: external systems can post via the CLI but have no listener to receive messages in real time, making conversation one-directional without manual polling. Three enhancements have been proposed — per-agent webhook registration, a buzz listen command maintaining a persistent WebSocket that streams events as JSON to stdout, and a generic stdio bridge mode accepting an arbitrary executable. None has shipped. If you need bidirectional external agents today, you are writing the polling loop yourself.

For teams running several agents across different harnesses, the operational problem shifts from connecting them to watching them. Open-source dashboards such as OpenClaw Mission Control exist for exactly this: a single view of which agents are alive, what they are doing, and where they stopped. Buzz gives agents a shared room; it does not give you fleet-level observability across harnesses, and those are different problems.

How to Create Channels

Channels are where the work happens, and in Buzz they are also the unit of agent scoping. Get this right and agent permissions become manageable. Get it wrong and you have a room with too much context in it.

In the Desktop App

Use the add-a-channel dialog, which supports search, filters, and both joining existing channels and creating new ones. Name it, describe it, and choose whether it is private. Spinning up a room takes seconds by design.

Practical guidance:

• Public channels are visible to community members.

• Private channels are invite-only. Use them for anything you would not want an agent in an adjacent room reading.

• Each channel keeps its own history and member list.

From the CLI

Because buzz-cli is agent-first, channel operations are scriptable, which matters when you want a workflow or an agent to create rooms:

bash

buzz --format compact channels list

Agents can create their own channels, take user-level actions through CLI commands, and update their own memories, while you set channel- or thread-specific rules for each agent. That capability is genuinely useful and genuinely worth scoping carefully.

Channel Design Patterns That Work

Branch as room. Open a feature branch and a channel appears. Patches land as signed git events, CI posts results, an agent runs a first-pass review, teammates react to the parts they care about, and the merge decision lands in the same room as the evidence. The channel becomes the record of why the code exists. Push a branch, get a channel.

Short-lived work channels. A feature or bug gets a temporary channel. A lead agent delegates to cheaper, faster workers. Discussion, patches, CI, review, and the signed merge decision share one record. The channel closes when the work does, and the reasoning survives in search.

One narrow channel per agent, at first. Agents in Buzz act on triggers, not just replies — workflows fire on a message, a reaction, a schedule, or a webhook. Scope the first channel narrowly, one repo and one workflow, until you have watched what the agent actually does under real events.

Implementation Details for Builders

If you are extending Buzz rather than just using it:

• Channel metadata uses kind 39000, not kind 41. All event kinds are defined in buzz-core/src/kind.rs, and new features get new kind integers added there first.

• Channels scope with h tags — the NIP-29 group tag — not e tags. Filters and queries must scope to h tags inside a channel.

• New agent-facing features belong in buzz-cli first, then the REST or WebSocket call.

• Prefer modeling operations as Nostr events over adding HTTP endpoints. You get realtime fan-out, scoping, and the existing auth pipeline free.

How to Invite People and Share Agents Across a Channel

This is the payoff. A single agent, configured once, serving a whole channel of people. Here is how the pieces fit.

Inviting People

Buzz uses invite links. An admin or owner generates one and shares it however they like. Recipients accept terms of service and a minimum-age step as part of joining.

Roles in the member list are Owner, Admin, and Agent — agents appear as a role alongside humans, which tells you a lot about the design philosophy.

Desktop supports multi-select invite for adding several members to a channel at once.

Two honest friction points:

1. Admin promotion has been confusing. Early users reported finding a screen for promoting community members to admin, then being unable to find it again. If you cannot locate it, you are not the only one.

2. Every teammate needs a keypair. That is a concept, not a click. If half your team will bounce at "generate and back up a cryptographic key," pilot with the half that will not.

Remember the mobile constraint from earlier: an invite link alone is not enough for a phone-only teammate. They need desktop first to establish an identity, then pair.

Sharing Agents Across Multiple People in a Channel

The core mechanic is refreshingly simple: add the agent to the channel the same way you add a person. Everyone in that channel can then @mention it, and everyone sees both the question and the answer.

That is the actual difference from a private agent session. Instead of one person prompting in a harness window and pasting results into chat, the exchange — question, answer, evidence — stays in the channel where the whole team can read it, correct it, and build on it. Block's framing is that nobody enjoyed being middleware between an agent and their team.

Access control layers on top:

• Channel membership is the primary scope. An agent sees the channels it belongs to. Scope by identity, the way you would scope a teammate, rather than by permission flags.

• Mention requirements. In shared channels, well-configured agents only respond when addressed. Without that, an agent in a busy channel becomes noise immediately.

• Allow-lists. Adapters like Hermes let you restrict which pubkeys can talk to an agent even inside a channel where it is a member. Private mode by default, community mode when you explicitly want everyone able to chat.

• Relay-enforced membership. Only community members can post at all. That check happens at the relay, not the client.

Multi-Agent Orchestration in Shared Rooms

This is where Buzz starts to look different from a chat app with bots in it.

The pattern Block describes internally: one frontier agent drives a swarm of cheaper, faster agents. The expensive one holds the big picture. The fast ones research, build, test, and review in parallel. They coordinate through ordinary Buzz mentions, injected into each other's active work almost immediately without breaking anyone's flow.

Two observations from that write-up are worth sitting with. First, the agents invented coordination behaviors nobody scripted — recruiting each other, splitting work into side channels, handing tasks across contexts. Second, and more useful: humans redirect work while it is happening, instead of waiting for a beautifully formatted wrong answer.

The visible history keeps the failed paths and the reasons behind the final call. Search a term six months later and find the report, the rejected fix, the patch, the review, and the final decision. A conventional forge preserves the diff and a green check. Buzz also preserves why the obvious fix was wrong.

Treat the enthusiasm appropriately — that account comes from the team that built the tool, describing their own usage. It is a credible report of internal experience, not an independent benchmark.

Agent Teams and Groups

Buzz has agent teams (kind 30176) — containers of persona IDs, essentially agent templates deployed into channels. Note the limitation: they hold personas, not pubkey memberships, and contain no humans.

A user groups feature has been proposed to fill the gap: named, mentionable groups containing both people and agents, since both are just pubkeys in this model. That is something Slack structurally cannot do. The kind registry already reserves an empty 47000–47999 range for it. The design covers group creation permissions, unique validated handles, bulk channel adds, and auto-joining default channels.

It is not shipped. Do not plan around it.

Shared Compute

One underdiscussed capability: Buzz can run an agent's model requests on another community member's machine. Buzz introduces authorized peers, then encrypted model traffic travels directly between them — letting a team share GPUs and inference capacity without routing prompts through the Buzz server.

For a community where one member owns capable hardware, that is a meaningful primitive. Live telemetry and cancellation travel as ephemeral encrypted messages; memory and cost records are encrypted but durable. By design the server sees routing metadata rather than those payloads.

Worth noting what this is not: reviewers looking for a built-in marketplace for shared GPU capacity, pooled inference billing, or a token economy have not found one documented in public materials. The capability is peer-to-peer inference routing, not a compute market.

Workflows: Automation Without Glue Code

Buzz ships YAML-as-code workflows with four trigger types, all working today:

• Message triggers

• Reaction triggers

• Schedule triggers

• Webhook triggers, exposed at /hooks/{id}

Conditions are evaluated with the evalexpr library, and the guidance from the codebase is to keep expressions simple and testable.

The canonical example: a workflow fires on a tag. An agent reads merged pull requests from project channels, drafts release notes, posts them for human review, gets a thumbs-up reaction, and ships. Every step signed. Every step searchable.

Caveat that matters for regulated teams: workflow approval gates are listed as still being wired up — the infrastructure exists but the glue is not finished. If your compliance story depends on enforced approval gates, verify current state before you rely on them.

The Git Forge

Buzz includes a built-in git forge over standard Git Smart HTTP, so teams can host repositories and manage reviews without a separate code host. Git events are first-class signed events using NIP-34: patches, repository announcements, and status. Git hosting backend and git events both work today; Block frames the forge UI as early.

The storage design is the interesting part, and it exists because of a real problem: git has always had a convenient rate limiter, which is humans. We sleep, eat, attend meetings, and occasionally think before pushing. Agents remove all of those limits. A group with agents can produce human-months of commits and CI runs in an afternoon, with many writers pushing concurrently.

So Buzz stores repositories as immutable, content-addressed packfiles plus a single mutable manifest pointer. A push writes objects first, then advances the pointer with a conditional compare-and-swap. That pointer update is the commit point — workspace events announce the change, they do not define it. The protocol was specified in TLA+ and model-checked for durability, reconstruction, and concurrent pushes, and the bounded result depends on three explicit object-store guarantees, so every backend must pass a conformance suite.

Also useful: git signing and credential helpers using Nostr keys ship as git-sign-nostr and git-credential-nostr, so the same identity that posts a message can sign a commit and authenticate a push.

Troubleshooting: Errors and Their Causes

Buzz Versus Slack Plus Bots

An honest comparison, because "Slack killer" framing obscures what is actually different.

Where Buzz genuinely differs:

• Agents hold their own keypairs. Every action traces to a signed authorization from a specific human.

• One event log covers chat, code patches, CI status, workflow runs, and approvals — so one search covers all of them.

• Revocation is per-agent, without disturbing the human identity behind it.

• Identity is portable. It is a keypair you hold, usable across Nostr-compatible systems. If Buzz disappeared, your signed history still verifies and git remains git.

• Self-hosting is a first-class path, not an enterprise upsell.

• Code and conversation share a room instead of linking to each other across tools.

Where Slack still wins today:

• Onboarding. Email invites versus keypair generation is not a close contest.

• Mobile maturity, especially push notifications.

• Compliance paperwork. None of the launch coverage claims SOC 2, HIPAA, or FedRAMP.

• Integration breadth built over a decade.

• Stability. Buzz is pre-1.0 software with unsigned Windows binaries at points during launch week and documentation that is sparse in places.

The unresolved objection worth taking seriously: a Slack employee raised data-leakage concerns specific to multiple agents operating in shared rooms. That criticism has an obvious interest behind it, and it is also the correct question. Shared context is the entire value proposition, and shared context is also the attack surface. An agent in a channel reads that channel's history. Scope channels accordingly, and treat every agent's channel membership as a data-access decision rather than a convenience toggle.

What Works Today Versus What Does Not

Block's own candor here is worth mirroring — the repository states plainly that Buzz is not finished and that they will tell you what works and what does not.

Working: relay, channels, threads, DMs, canvases, media, search, audit log, desktop app, buzz-cli with the ACP harness for goose, Codex, and Claude Code, YAML workflows with all four trigger types, git events over NIP-34, git hosting backend, and official mobile apps on both stores.

Being wired up: mobile clients, workflow approval gates, huddle lifecycle events.

Aspirational, no code yet: push notifications, web-of-trust reputation across relays, culture features. Block explicitly asks readers not to plan a compliance program around this column, and that request should be honored.

Gaps the roadmap does not cover: standalone mobile identity, bidirectional external agent transport, shipped user groups, published hosted pricing.

Who Should Use Buzz, and Who Should Wait

Good fit:

• Teams already running multiple agents across goose, Claude Code, or Codex and coordinating them through ad-hoc scripts, tmux panes, or a Slack channel full of bot spam.

• Open-source maintainers interested in hosting a project where discussion, code, and agent work share one record.

• Anyone with a hard requirement to own the infrastructure their agent identities and history live on.

• Builders who want to work against an open agent-collaboration protocol early.

Wait, for now:

• Solo developers and two-person teams. The value is humans and agents coordinating in shared rooms. With no team, existing tools do this with fewer moving parts.

• Anyone who needs mobile as a primary surface, given the desktop dependency and missing push.

• Teams that cannot absorb onboarding friction, since keypair generation is a real conceptual step for every member.

• Organizations needing mature compliance certifications this quarter.

• Anyone wanting a Slack replacement without the git and agent parts. Buzz is heavier than Slack; using it for chat alone is over-tooling.

A Sensible Evaluation Plan

If you want a real read rather than a launch-week impression:

1. Self-host locally. Ten extra minutes buys you a working relay and skips the hosted auth funnel entirely.

2. Start with one channel and one measurable workflow. Resist the urge to migrate anything.

3. Add one agent with a narrow job. Reviewing diffs on a throwaway repository is a good first task.

4. Watch it under real triggers. Workflows fire on messages, reactions, schedules, and webhooks. Observe before widening scope.

5. Test the exit. Can you export your data? Does your signed history verify independently? Can the git repositories be rehosted? A protocol that anyone can rebuild is a protocol nobody can lock you into — but verify that claim yourself rather than accepting it.

6. Ask the coordination question honestly. Did the shared record save time, or did it just relocate the same work? Did agents stay controllable?

Twenty minutes of hands-on will tell you more than any launch post, including this one.

Frequently Asked Questions

Is Buzz free? The software is Apache 2.0 and self-hosting is free. Block offers managed hosting at buzz.xyz, currently in a free beta with no published pricing for the tier. Do not read the license as a permanent pricing commitment.

Can I use my existing Claude Code subscription? Yes. That is the point of harness neutrality. Wire Claude Code through ACP, keep your existing subscription and billing, and Buzz becomes the room the agent works in. Claude Code itself requires a paid Claude plan.

Do I need to self-host? No, but it is the better evaluation path today given hosted onboarding bugs, and it is the only path if hosted content not being end-to-end encrypted is disqualifying for you.

Can my team use it on phones only? Not today. The mobile app has no standalone identity path and must receive one from a desktop app over device pairing.

Is Buzz a blockchain project? No, and the repository addresses this directly. Signed events provide auditability and identity. There is no coin.

What happens if Buzz shuts down? Your identity and signed history still verify, and git remains git and can be rehosted. That is the argued benefit of building on an open protocol — worth verifying against your own data before you depend on it.

How does it compare to Slack bots? Slack bots share one account and one token, so every action looks the same. Buzz agents each hold a keypair, and every action ties back to the human who authorized it. Meaningful for accountability; also more setup.

Is it production-ready? Not for most definitions. It is pre-1.0, moving fast, and honest about that. Block runs its own company on it, which is a strong signal — but Block also has the engineers who wrote it.

Where This Goes

The falsifiable version of Block's bet is straightforward: if Buzz does not attract meaningful external developer adoption, and no third-party relay ecosystem emerges within twelve months, then Buzz is an internal tool that Block open-sourced rather than proof that Nostr scales to enterprise coordination.

The signals to track are specific. How many self-hosted relays run outside Block. Whether open-source communities migrate project hosting onto it. Whether third-party clients and adapters keep arriving. Early evidence on the last point is positive — Hermes and Armada both shipped support within weeks.

What makes Buzz worth watching regardless of whether Block wins is the underlying claim: that agent collaboration infrastructure should be open, and that companies should own their AI workspace the way they own their code. Whether or not this specific implementation lasts, the identity primitive it ships — a keypair that belongs to the participant rather than to the platform — is the part other tools will have to answer.

Anyone building or deploying agents right now benefits from putting their hands on it. Not because it will replace your stack this quarter, but because it is a working argument about how humans and agents should share a room, and arguments are easier to evaluate when they compile.

The infrastructure lesson generalizes past agents, too. Whether it is where your agent identities live, where your repositories are hosted, or simply where your project's site is served from, the pattern that holds up over time is the same: understand exactly what you own and exactly what you are renting. Platforms like www.dplooy.com for static hosting and Buzz for agent workspaces are answering that question in different layers of the stack, but it is the same question.

Getting started, in order:

1. Read the honest status table in the repository README before anything else.

2. Self-host locally with Docker and Hermit — four commands.

3. Install Claude Code or goose and wire the harness in Desktop.

4. Create one narrow channel, add one agent, give it one job.

5. Pair your phone from desktop once identity is set up.

6. Invite one teammate and watch what a shared agent actually changes.