What is Buzz from Block?
Buzz is an open-source, self-hostable workspace from Block where people and AI agents can participate in shared channels and conversations. The project brings communication, agent activity, workflows, and development-related events into a common workspace.
Its backend uses a Nostr relay, a server that accepts and distributes signed events. In practical terms, messages and other activities can share an identity and event history whether a person or an agent produces them. For a business owner, the useful question is whether that shared working context improves a specific team process.
Where could a shared agent workspace help?
Consider a task that moves between a person, an assistant, and another reviewer. The request might live in chat, the supporting work in a separate tool, and the decision in a later conversation. A shared workspace can make those handoffs easier to follow when the team uses it consistently.
Buzz documents an agent harness using the Agent Client Protocol (ACP). Its examples include Goose and adapters for Codex and Claude Code. The workspace and the connected agent runtime have separate responsibilities. The agent still needs the appropriate tools and permission to reach a business system.
- Research where the requester, draft, supporting links, and review stay together.
- Internal project coordination with an agent preparing status updates for a named reviewer.
- Software work where discussion and development events need a common place to be inspected.
Separate current capabilities from the product vision
The project README distinguishes working features, in-progress work, and ideas awaiting implementation. It lists channels, threads, search, an audit log, a command-line interface, and workflow triggers among its working capabilities.
Treat that distinction as part of the evaluation. Check the exact release for the clients, notifications, access controls, and approval behavior your workflow needs. Roadmap language describes intent. Acceptance should come from trying the required behavior on the version you plan to run.
Buzz versions its desktop, relay, and mobile releases independently. Record which pieces you tested together and check compatibility before upgrading a working setup.
An example pilot: one team, one recurring research task
Imagine an operations team that reviews supplier options each week. A coordinator posts the question and selection criteria in one project channel. An agent prepares a comparison using approved public sources, with links for the reviewer to inspect. A manager records the decision and the next action in the same conversation.
Keep purchasing and external communication outside this first pilot. The test is whether the team can find the request, check the evidence, identify the reviewer, and understand what was decided. A recorded reaction or signed event should not be treated as proof that a purchase or data change was authorized.
This is a proposed use case. Actual behavior depends on the connected agent, the workflow configuration, and the release. Verify approval enforcement on that build before granting consequential actions.
What does owning the workspace involve?
Self-hosting gives the operator responsibility for keeping the workspace available. Buzz's production Compose documentation describes a deployment with services such as Postgres, Redis, object storage, and optional TLS termination. The development setup and production deployment have different purposes.
Plan who manages hosting, backups, updates, user access, and recovery. Agent runtime or model-provider costs can add to that operating budget. Open-source availability alone does not settle the full cost of a working team service.
The signed-event design helps establish which key produced an event. Correctness, appropriate access, and a valid business decision still need their own checks. Give people and agents clear responsibilities and retain an independent recovery path for the workspace.
How does Buzz relate to OpenClaw?
The two tools emphasize different parts of the workflow. OpenClaw centers on an assistant connected to messaging, models, and tools. Buzz centers on a workspace where a team and its agents share context and activity.
Choose based on the problem. An owner who needs a recurring assistant workflow can evaluate that workflow directly. A team coordinating several people and agents may have a separate need for a shared workspace. A connection between specific products needs its own technical verification.
Rowvyn's take: prove the coordination value first
Start with one team and one process, using information that is appropriate for a pilot. Compare it with how the team works today: can people locate the evidence, understand the handoff, and reach a reviewed decision with less confusion?
If the current chat tool and a separate assistant already cover the job, another workspace may add overhead. If fragmented context is the problem, a focused Buzz pilot can test that assumption before a wider migration. Decide what would count as success and who will own the result.
Sources and review notes
This is an independent, documentation-based evaluation of Block’s Buzz. The pilot is illustrative; this article makes no client-deployment or performance claim.
Features and availability can change; check the current official documentation before choosing a setup.
Last reviewed: