Buzz: Block's Agent-Native Messaging Layer on Nostr

Block open-sourced Buzz on July 21, 2026, under Apache 2.0. The tagline in the repo is the whole thesis: "A workspace where humans and agents build together, on a relay you own."

That sounds like marketing until you read the architecture. Buzz is not Slack with a better bot API. It is a Nostr relay with a chat client attached, and the difference shows up in exactly the place multi-agent systems keep breaking: identity.

The Problem With Slack-Plus-Bots#

If you have wired agents into Slack, you know the shape of the pain.

Your agent is a bot token. The token belongs to an app, the app belongs to a workspace, and the workspace belongs to a vendor. Everything the agent does is attributed to "YourBot" regardless of which agent instance actually did it. Run five agents through one app and the audit trail collapses into a single blurry actor.

Permissions are scoped to the app, not the agent. You cannot give the triage agent read access to one channel and the deploy agent write access to another without provisioning separate apps, separate tokens, and separate install flows. This is the same trap we covered in Agent Identity Is the Missing Security Layer for AI Workflows: when the identity primitive is a token issued by a platform, your access model can only be as expressive as that platform's token model.

And the history is not yours. Messages live in a vendor database. Export is a support ticket. There is no cryptographic proof that a given message came from a given actor, only the platform's assurance that it recorded things correctly.

What Buzz Does Instead#

Every action in Buzz is a signed Nostr event. Not just chat messages: reactions, workflow steps, canvas updates, presence, and repo events all become events identified by a kind integer, signed with a secp256k1 key.

Agents get their own keypairs. From the architecture doc, agents are "cryptographic identities using secp256k1 public keys (same as humans)." They authenticate over NIP-42, hold scopes like MessagesWrite and JobsRead, and their messages are signed by their own key. Not the app's key. Theirs.

That single change fixes several things at once:

Attribution is cryptographic. A message signed by agent pubkey X was produced by whoever holds X's private key. You are not trusting a platform's bot_id field, you are verifying a Schnorr signature. When a multi-agent run goes sideways, the log tells you which agent did what without you having to instrument anything.

Scopes attach to the actor. Because each agent is its own identity, you scope access per agent rather than per app. The repo describes this as scoping agent access "by identity rather than permission flags."

History is portable. Nostr events are self-contained and self-authenticating. Move them to another relay and the signatures still verify. Your team's history does not need the original vendor to remain meaningful.

New features do not break old clients. From the architecture notes: "Adding a new feature means defining a new kind number; existing clients see nothing and break nothing." Buzz reserves 40000 to 49999 for its own kinds. Canvas is kind 40100. Workflow events sit in the 46001 to 46012 range.

There is also a tamper-evident audit layer. The buzz-audit crate does SHA-256 hash chaining over the event log, per community, so history is append-only in a way you can actually check. That is the receipts problem we wrote about in Agent Swarms Need Receipts, solved at the protocol layer instead of bolted on.

The Relay Is Deliberately Boring#

Worth being clear about what Buzz is not. Despite the Nostr foundation, this is not a peer-to-peer system.

The architecture doc is blunt: the relay is the single source of truth, all reads and writes flow through it, and there is "no peer-to-peer event exchange, no gossip, no replication." Clients connect to one relay over WebSocket. The relay authenticates, verifies signatures, persists, fans out to subscribers, indexes, and triggers automation.

That is a good call. You get Nostr's identity and portability properties without inheriting distributed-systems consistency problems in your team chat. It is a normal server that happens to speak a signed, open wire format.

The stack underneath is conventional and self-hostable: Rust workspace, Axum WebSocket server, Postgres for events and full-text indexing, Redis for pub/sub and presence, S3 or MinIO for media. Production deploys use the deploy/compose/ bundle. Development needs Docker and Hermit, or Rust 1.88+, Node 24+, and pnpm 10+.

Desktop clients ship for macOS, Linux, and Windows. Mobile is in development via Flutter.

The CLI Is the Interesting Part#

buzz-cli is described in the repo as agent-first: JSON in, JSON out. This is the surface that matters if you are building multi-agent systems, because it means an agent can operate the workspace as a tool without a browser, a webhook tunnel, or an OAuth dance.

Configuration is two environment variables:

export BUZZ_RELAY_URL="https://relay.yourteam.example"
export BUZZ_PRIVATE_KEY="nsec1..."

BUZZ_RELAY_URL defaults to http://localhost:3000, so a local relay needs no configuration at all. BUZZ_PRIVATE_KEY is the NIP-98 signing key in nsec1... format. On Windows, BUZZ_SHELL points at a bash-compatible shell.

Basic operations look like this:

buzz channels list | jq '.[].name'
buzz messages send --channel <uuid> --content "Deploy finished, tests green"

Exit codes are specified rather than improvised, which matters when a script is the caller:

0  success
1  user error
2  network error
3  authentication failure
4  other error
5  write conflict

Exit code 5 is the one worth noticing. A dedicated write-conflict code means an agent can distinguish "someone else changed this first, re-read and retry" from "you are unauthorized" without parsing an error string. That is a small design decision that saves a lot of brittle retry logic.

Agents as a First-Class Subcommand#

buzz agents manages agent identities directly. The subcommands are draft-create, draft-update, archive, unarchive, and archived.

buzz agents draft-create \
  --channel <uuid> \
  --display-name "Release Bot" \
  --system-prompt "Summarize merged PRs and flag failed checks."

draft-update extends this with --runtime, --provider, --model, and --respond-to, so the model backing an agent is a property of the agent record rather than something baked into a separate deployment.

Note the lifecycle verbs. archive takes --reason and --replaced-by. Retiring an agent is a recorded event that points at its successor, not a token you quietly revoke. When you are running a fleet that turns over regularly, having supersession in the log is the difference between an audit trail and a mystery.

Workflows#

buzz workflows covers list, get, create, update, delete, trigger, runs, and approve. Definitions are YAML-as-code with four trigger types (message_posted, reaction_added, schedule, webhook) and seven actions (send_message, send_dm, set_channel_topic, add_reaction, call_webhook, request_approval, delay).

The approve subcommand plus the request_approval action is the human-in-the-loop seam. An automation can pause and wait for a person, and that approval is itself a signed event.

Be aware of the current state, though. The architecture doc lists approval gates as a known limitation (WF-08): "runs that hit an approval gate are marked as failed." send_dm and set_channel_topic return NotImplemented rather than being wired end to end. The relay also has no production rate limiter yet, only a test stub. This is a July 2026 open-source release, not a mature product, and the repo is honest about it.

The declarative model is still the right shape. We argued the general case in Agent Workflows as Code: a state machine you can diff and version beats a prompt asking a model to remember a checklist.

Pack Runs Without a Relay#

buzz pack validate and buzz pack inspect operate locally, no relay connection required. Pair that with buzz-persona agent persona packs and you can validate agent definitions in CI before anything touches a live workspace.

There is also buzz mem (ls, get, hash, set, patch, rm), a keyed store agents can read and write. It is a modest primitive, but shared mutable state that every participant can address by slug is exactly what a fleet needs to coordinate without stuffing everything into the conversation.

Channels With Canvas#

Canvas is a first-class event kind (40100), not a document embedded in a chat message. A channel carries a persistent shared surface alongside its message stream, and canvas updates fan out through the same relay pipeline as everything else.

For agent work this is more useful than it sounds. Conversation is a poor place to keep current state, because the newest message is not necessarily the truest one. A canvas gives agents a place to write the current plan, the current diff under review, or the current task board, where reading it does not mean replaying a thread. That is the workspace-contract idea from Agent Workspaces Need Filesystem Contracts, applied to a chat surface.

Buzz also carries repo primitives (buzz repos, buzz patches, buzz pr, buzz issues), which is how it earns the "Slack and GitHub in one" framing in the coverage. Branch discussion, patches, and approvals land in the same signed event log as the conversation about them.

Model Support#

The buzz-acp crate is an Agent Client Protocol harness bridging relay events to agent subprocesses over stdio JSON-RPC, with per-channel queueing so at most one prompt is in flight per channel. It supports Goose (Block's own open-source agent framework), OpenAI Codex, and Claude Code.

Because the harness speaks ACP rather than a vendor-specific API, the model layer is swappable. There is also buzz-dev-mcp, exposing shell and file-edit tools to agents in the workspace.

Who Should Care#

If you run a multi-agent fleet, the identity model is the reason to look. Per-agent keypairs, per-agent scopes, and a signed hash-chained log give you attribution and access control that bot tokens structurally cannot. The self-hosted relay means the coordination substrate is infrastructure you own rather than a rate-limited API you rent.

If you are evaluating agent infrastructure generally, Buzz is a useful reference implementation even if you never deploy it. The Rust workspace is small, layered, and readable, and the architecture doc documents its own limitations instead of hiding them. Reading how a team solved fan-out with membership boundaries (global subscriptions deliberately never receive private-channel events, regardless of filter match) is worth the hour.

If you just want a Slack replacement today, wait. Approval gates do not complete, two workflow actions are unimplemented, mobile is in progress, and there is no production rate limiter. The interesting part of Buzz right now is the model, not the polish.

The bet Block is making is that agents will be numerous enough and consequential enough that treating them as second-class integrations stops working. When you have thirty agents doing real work, "which bot did that" needs a better answer than a shared token. Buzz's answer is a signature. That is the right primitive, and it is worth understanding whether or not this particular implementation is the one that wins.

Sources#

• github.com/block/buzz - repository, README, and release
• buzz/ARCHITECTURE.md - relay design, event kinds, agent identity, workflow engine, known limitations
• buzz/AGENTS.md - agent surface and conventions
• Decrypt: Block launches Buzz - launch coverage and date

Continue Reading#

• Agent Identity Is the Missing Security Layer for AI Workflows - why token-based agent identity fails as fleets grow
• Agent Workflows as Code: Why State Machines Beat Prompt Checklists - the declarative automation argument Buzz's YAML engine implements
• Agent Swarms Need Receipts - auditability as a requirement, not a feature
• Agent Workspaces Need Filesystem Contracts - shared state agents can address directly
• Agent Sandbox Architecture: How to Choose the Right Runtime Boundary - pairing identity scoping with execution isolation