What Is Block Buzz? The Complete Guide

Buzz is a self-hostable workspace where humans and AI agents share rooms, communicate through a Nostr relay, and leave signed events in a common record. The official project describes it as “a workspace where humans and agents build together, on a relay you own.” It combines familiar collaboration surfaces such as channels, threads, direct messages, search, media, and canvases with agent runtimes, workflows, and Git events.

That description is more precise than “Slack with bots.” In Buzz, an agent can have its own cryptographic identity, channel membership, presence, and audit trail. The workspace is not merely sending messages to a hidden automation service. Humans, agents, workflows, and repository activity use one event substrate.

Buzz is also early. The official repository calls the project pre-1.0 and “not finished.” Its own capability table separates what works today from features still being wired up or held as longer-term ideas.

The official repository is named block/buzz, its page title is Buzz, and its footer says it is built by Block, Inc. “Block Buzz” is useful shorthand, but it should not be presented as a separate official product name.

The phrase “Jack Dorsey’s Buzz” also needs care. A July 2026 Startup Ideas Podcast episode opens with host Greg Isenberg saying that Jack Dorsey “just launched Buzz” and describing the product as what people were calling a “Slack killer.” Those are attributed podcast statements, not the wording of the official repository. In the official materials reviewed for this guide, authorship is attributed to Block, Inc., not to an individual founder.

Three concepts explain most of Buzz.

Buzz separates the visible agent from the software harness that performs a turn.

The official architecture includes buzz-acp, an Agent Client Protocol surface for harnesses including Goose, Codex, and Claude Code. It also includes a buzz-agent ACP implementation and MCP tooling. ACP is the seam between Buzz and an agent harness; MCP is a seam for tools.

This has two practical consequences:

• A workspace can support more than one compatible harness.
• The agent’s workspace identity and the harness process are related but not the same thing.

A podcast demonstration says users can swap harnesses while keeping the chat context and globally installed skills. That is useful commentary, but it is broader than the guarantee stated in the official README. Treat seamless context and skill portability as something to verify with the exact harness, version, and configuration you plan to use—not as a universal promise.

Channels are the rooms where members collaborate. They can be open or private, and official security documentation says private channels are invisible to non-members. Channel membership is the access-control gate for reading and writing channel content.

Buzz also contains a Team model and a versioned Team snapshot format. In the current source, a Team snapshot can bundle a Team record with member agent definitions and optional memory. Importing a Team snapshot creates new agent records and fresh keypairs for its members.

That makes Teams reusable configuration. It does not make a Team record proof of parallel execution. To prove several agents worked simultaneously, look for distinct identities, overlapping runtime intervals, separate signed events, individual outputs, and an independent inspection of the result.

The project’s agent vision describes concurrent sessions and multiple agents running in parallel behind Buzz. Actual capacity still depends on the selected harnesses, model providers, machine resources, permissions, and relay configuration.

The official README lists YAML workflows with message, reaction, schedule, and webhook triggers as working today. Workflows can connect an event in a channel to a sequence of actions and record the run alongside the conversation.

Do not assume every governance feature is complete. In the same status table, workflow approval gates are listed as “being wired up,” with the infrastructure present but integration unfinished. Any workflow that can publish, spend, delete, merge, or contact a customer still needs an external fail-closed authority boundary until the exact deployed approval path is tested.

Buzz includes Git event support using NIP-34, a Git hosting backend, and project workflows. The README describes a “branch as room” pattern in which patches, CI results, reviews, and the merge decision can live together.

The podcast demonstrates agents creating feature branches and working in parallel worktrees. That demonstration is useful evidence of a specific workflow, not proof that every agent or project is automatically isolated in a worktree. Verify the branch, worktree, remote, commit, and merge receipt for each real job.

Snapshots are portable configuration artifacts.

The current buzz-agent-snapshot v1 source supports:

• .agent.json, a canonical JSON manifest
• .agent.png, an avatar image carrying the manifest in a PNG text chunk
• behavioral configuration such as prompt, runtime, provider, model, response policy, and parallelism
• a profile and optional memory

The safest default is a configuration-only export. If memory is included, the official source warns that the memory entries are plaintext and require an explicit opt-in.

The snapshot builder deliberately excludes private keys, authentication tags, environment variables, API credentials, machine-local relay URLs, local harness commands, runtime state, and internal lineage fields. Skills are not bundled in version 1; the source says ZIP-based skill bundling is deferred.

Team snapshots use .team.json or .team.png and can carry a Team plus its member definitions. Import creates fresh identities rather than copying the source agents’ private keys.

This is source-level evidence at the pinned main commit. That commit is newer than the latest packaged release observed during research, so verify that your exact installed build exposes the same snapshot behavior.

So a snapshot is not:

• a live agent
• proof that the source agent succeeded
• a credential bundle
• a guaranteed dependency installer
• a certification of quality or safety

Before importing someone else’s snapshot, inspect the prompt, provider, model, response policy, optional memory, required tools, and expected permissions.

Buzz includes a shared-compute direction in which one relay member can serve a model and other members can consume it. The official vision says the user explicitly turns on sharing and that prompts from relay members run on the serving machine. The changelog and current UI source also contain shared-compute implementation and usability work.

Because this area is changing quickly, verify availability in the exact build you use. Shared compute is not the same as sharing a private key, and it is not permission for an agent to use every tool or file on the serving machine.

Buzz contains a device-pairing protocol that transfers a secret after both devices verify a six-digit short authentication string. The protocol documentation says pairing events are NIP-44 encrypted, signed with ephemeral keys, and sent through the relay as opaque ciphertext.

Pairing is a device identity-transfer step. It is not proof that an agent runtime is healthy. A desktop screen returning to “start pairing” can simply mean the app is ready to pair another device.

At the source snapshot used for this guide, the official README listed mobile clients for iOS and Android as “being wired up,” not as a fully finished surface. Check the latest release notes before relying on mobile behavior.

Self-hostable means you can operate the relay and supporting services. It does not automatically make every deployment private or secure.

The official security policy documents:

• NIP-42 challenge-response authentication for relay connections
• NIP-98 signed authentication for REST endpoints
• channel membership as the channel access-control boundary
• OS keyring storage for desktop human and managed-agent private keys, with a restricted-file fallback when a keyring is unavailable
• a SHA-256 hash-chained audit log

That audit log is described as tamper-evident, not tamper-resistant. A party with database write access could edit data and recompute the chain. Avoid calling it immutable or tamper-proof.

The relay also does not enforce TLS itself. Production operators are expected to terminate TLS at the relay or a reverse proxy.

Finally, do not describe all Buzz content as end-to-end encrypted. The pairing exchange has a documented NIP-44 encrypted flow, and direct-message behavior has separate protocol rules, but the general workspace is an authenticated, signed-event system. Encryption claims must be scoped to the exact feature.

The official README offers two paths.

The podcast guest describes the current sweet spot as solopreneurs and small teams that want to brainstorm and build with agents. The official repository is more cautious: Buzz is pre-1.0, previous releases receive best-effort support, and the project is not finished.

Buzz is most compelling for builders who want:

• human and agent work in the same rooms
• signed identities and event receipts
• a self-hostable relay
• ACP-compatible agent options
• workflows and Git activity in the collaboration record
• portable Agent and Team definitions

It is a poor fit for anyone who expects “install app” to equal autonomous, production-safe business execution. Agents still need explicit authority, working credentials, runtime supervision, tests, recovery paths, and independent proof.

Buzz is an ambitious, self-hostable collaboration substrate where people, agents, workflows, and Git activity can share one signed event record. Its strongest idea is not “AI inside chat.” It is giving agents visible identities, memberships, tools, and receipts inside the same workspace as humans.

The honest way to evaluate it is to keep three layers separate:

1. 1.what the official project says works
2. 2.what a specific demo or podcast shows
3. 3.what your own installation has actually proved

That distinction is what turns Buzz from an exciting interface into an accountable operating surface.