---
title: >-
  Block Put Its Agents in the Team Chat. Buzz Is an Audit Log Before It Is a
  Slack Killer.
dek: >-
  Block's open-source workspace gives agents identities, channels, code, and
  signed histories. Three early deployments show both the point and the missing
  permissions.
slug: block-buzz-agents-team-chat
publishedAt: '2026-08-07'
author: diego-ferraro
reviewedBy: Agnel Nieves
pillar: the-stack
tags:
  - buzz
  - block
  - ai-agents
  - open-source
  - nostr
  - slack
  - developer-tools
summary: >-
  Block's Buzz combines team chat, agent runtimes, workflows, and Git events on
  a self-hostable Nostr relay. The strongest evidence comes from three early
  uses: Block's preconfigured internal build, Jupiter Broadcasting's public
  community and Hermes integration work, and a membership-gated community asking
  for channel-scoped guest access. Buzz has a sharp identity model and a real
  permissions gap, so small engineering teams should pilot it while enterprises
  wait.
draft: false
featured: false
listen: true
heroImage: /blog/block-buzz-agents-team-chat.webp
heroImageAlt: >-
  Engraved illustration of an open ledger with gold seals on a stone pedestal
  amid oak leaves and blossoms, two top-hatted figures with quills and scrolls
  below, spot color gold on blue background.
heroVideo: /blog/block-buzz-agents-team-chat.mp4
ogImage: /blog/block-buzz-agents-team-chat-og.jpg
assetCredit: Hero illustration and animation generated with Grok.
audioEn: /blog/block-buzz-agents-team-chat.en.mp3
audioDurationSeconds: 587
audioCredit: Synthesized via Kokoro (am_puck).
---

The most revealing line in Block's Buzz repository is written for employees.

Do not use the public build, it says. Download the internal version from `squareup/buzz-releases`. That build already points at Block's relay and agent provider.

Block is using a separate, preconfigured version of its open-source workspace inside the company. That is a stronger case study than the launch claim that Buzz might replace Slack and GitHub. It tells us the product has crossed the line from demo to working infrastructure for at least one team, while stopping well short of proving an enterprise migration.

Buzz launched publicly on July 21. It puts people and AI agents in the same channels, gives each agent a cryptographic identity, and records messages, code patches, approvals, and workflow events in one signed log.

The Slack comparison explains the interface. The audit log explains the product.

## What Block built

Buzz is a self-hostable workspace built on the Nostr protocol. A workspace maps to a relay URL. Every message, reaction, workflow step, review approval, and Git event becomes a signed Nostr event stored by that relay.

Humans and agents use the same identity shape. Each participant has a public key, and every event carries a signature. Agents can join channels, open repositories, send patches, review code, run workflows, edit canvases, and call other agents.

The relay remains the source of truth. Postgres stores events, channels, workflows, tokens, and the audit chain. Redis handles presence and fan-out. The desktop application uses Tauri and React. `buzz-cli` gives agents a JSON-in, JSON-out interface. Agent Client Protocol (ACP) adapters connect Claude Code, Codex, Goose, and other compatible harnesses.

Here is the practical difference:

| Existing team stack | Buzz |
| --- | --- |
| A Slack bot posts under an integration account | An agent joins as a named member with its own key |
| The agent works in a private terminal session | Its channel, tool calls, patches, and replies can share one record |
| GitHub holds the patch while Slack holds the decision | Git events and conversation use the same event log |
| Bot permissions live across OAuth apps and service tokens | Relay membership, channel membership, and agent identity sit in one system |
| Search reconstructs a decision from several products | Search can query the conversation, patch, workflow, and approval together |

Buzz does not make the underlying model safer. It makes authorship and history easier to inspect.

## Case one: Block has an internal relay

The public README gives Block employees their own installation path. The internal build comes wired to the company relay and agent provider. Jack Dorsey's launch post said the project was built to reduce Block's dependence on Slack and GitHub.

Those two facts support a careful conclusion. Block has deployed Buzz internally and wants it to absorb work now split across incumbent tools.

They do not tell us how many employees use it, how much traffic it carries, or whether any team has removed Slack or GitHub. Block has published no migration percentage, retention number, or incident record.

The internal build still matters. Block is testing the identity model against its own agent work instead of asking open-source users to discover every rough edge first.

The release notes focus on problems active teams encounter. Version 0.5.0 shipped on July 28 with use-limited invite links, a generic ACP runtime seam for bringing another harness, agent display names as Git authors, a lower default parallel-agent limit, and a security update for a Nostr denial-of-service advisory.

Identity, invitations, Git attribution, runtime compatibility, and resource limits are not landing-page features. They are the problems a working room produces.

## Case two: Jupiter Broadcasting opened a community

Jupiter Broadcasting linked a live Buzz community from its July 26 episode of LINUX Unplugged. The episode page also points to external-agent integration work for Hermes, a multi-agent system the network has been testing.

This is an early outside deployment, not a customer success story. Jupiter already runs a technical community across several open tools, which makes it unusually tolerant of beta infrastructure. Its use still tests something Block cannot prove alone: whether a community that values self-hosting will move conversation and agents into the same room.

The linked work is specific. A feature request asks Buzz to support external agent systems that do not speak ACP. Related pull requests add Hermes runtime discovery and document the host integration.

That is open-source adoption in its least polished form. A real community wants to bring an existing agent stack, finds the protocol seam too narrow, and contributes the missing adapter.

## Case three: A real permissions gap appeared in two days

On July 23, an operator filed a request for channel-scoped guest access. They run a membership-gated Buzz community with internal channels and agents. They want customers to enter one public support channel without gaining access to anything else.

As of July 29, Buzz cannot express that policy.

The relay can require membership for everyone or accept authenticated identities more broadly. Channel visibility applies after relay admission. The operator wants a guest to read and write in `#support` while blocking every other channel, repository, workflow, direct message, and administration surface.

This issue is the best early case study in the repository because it shows the product working and the authorization model failing at the same time.

Cryptographic identity answers who signed an event. It does not automatically answer which event that identity should be allowed to publish. The operator wrote out the missing contract in detail: one allowlisted channel, text-only at first, normal moderation and rate limits, agents allowed to answer, and no broader relay membership.

That request is more useful than another screenshot of an agent posting in chat. It names the boundary a production community needs.

## The product claim that holds up

Block says agents should be members instead of bots. That claim holds up in the architecture.

Buzz's agent runtime uses two small Rust binaries. `buzz-agent` speaks ACP, calls a model, and manages sessions. `buzz-dev-mcp` gives the agent a shell and file editor through the Model Context Protocol (MCP). The pieces communicate through published protocols, so teams can swap the model provider or agent harness without rebuilding the workspace.

Each community keeps its own profiles, presence, direct messages, memories, jobs, memberships, and audit trail. The same public key can join another community, but the agent's state does not silently follow it across hosts.

Portable identity does not become portable access by accident, which is the safer boundary.

## The Slack-killer claim is early

Buzz has desktop applications, chat, channels, threads, direct messages, canvases, media, search, Git events, workflows, and an agent-first command-line interface. It also says plainly that it is unfinished.

As of July 29, the public roadmap still lists workflow approval gates and parts of the mobile experience as active work. Hosted relays are free during beta, with no published enterprise price or final usage limits. Slack Connect, mature retention controls, enterprise discovery, identity-provider integration, and years of administration tooling do not disappear because Nostr events have signatures.

The self-hosting story carries work too. A production relay brings Postgres, Redis, object storage, backups, updates, key recovery, monitoring, and incident response. Teams gain control because they accept the operating burden.

Buzz may reduce seven tabs to one substrate. It also puts seven products' worth of responsibility onto that substrate.

## Who should pilot it

A small engineering team or open-source community should run a pilot when agents already perform real work and the private agent conversation keeps vanishing from the team record.

Use one repository, two agents, and one workflow. Give the research agent read-only access. Give the coding agent a disposable branch. Require a human reaction before a workflow can publish or merge. Measure how often teammates can reconstruct a decision from Buzz alone and how often they return to Slack or GitHub for missing context.

Keep the incumbent tools during the pilot. Buzz has not earned a cutover.

Teams with regulated data, complex guest access, large Slack Connect networks, or mature GitHub governance should wait. The channel-scoped support issue shows why. Signed events are valuable, but authorization still needs the boring policy work.

## Verdict

Buzz has the most coherent method I have seen for tying agent work to an identity, an authority, a room, and a body of evidence.

Block's internal build proves the company is willing to use its answer. Jupiter Broadcasting proves an outside community can extend it. The support-channel request proves the permissions model still has sharp edges.

Pilot Buzz as an agent workspace. Do not call it a Slack and GitHub replacement until a team publishes the migration numbers and the authorization gaps close.

## Sources

- [Block, Buzz open-source repository and internal installation path](https://github.com/block/buzz)
- [Block, Buzz architecture](https://github.com/block/buzz/blob/main/ARCHITECTURE.md)
- [Block, Buzz agent runtime design](https://github.com/block/buzz/blob/main/VISION_AGENT.md)
- [Buzz Desktop v0.5.0 release notes](https://github.com/block/buzz/releases/tag/v0.5.0)
- [GitHub issue 2475, channel-scoped guest access for a membership-gated Buzz community](https://github.com/block/buzz/issues/2475)
- [Jupiter Broadcasting, LINUX Unplugged 677: We Got a Buzz](https://www.jupiterbroadcasting.com/show/linux-unplugged/677/)
- [The New Stack interview with Block's Bradley Axen](https://thenewstack.io/block-buzz-agent-workspace/)