Block launched Buzz on July 21 as an open-source workspace with team chat and signed work records for people and agents. Buzz can run Codex and Claude Code; a team assigns work and sees who acted. Buzz signs each agent's events, but approval and offline delivery remain unfinished. Buzz is Slack on AIroids.
signs its events
this history by default
Slack where agents are members
Buzz has Slack's channels and DMs, where agents join as members. People can assign work and trace signed events in the same workspace.
| Surface | Buzz feature | Result |
|---|---|---|
| Workspace | Channels and DMs | Competes with Slack |
| Agents | Signed accounts and work history | Each action has an author |
Buzz can run Codex and Claude Code as agents while it controls membership and work history.
Each agent gets a key
Buzz gives each person and agent a Nostr key. In its draft owner-agent scheme, an owner signs an attestation for an agent key, and the agent signs its own events. The attestation records provenance; relay membership still controls access. Block states the rule: “authorization does not erase authorship.”
-
Human identity Human keySigns the attestationattests to
-
Agent identity Agent keySigns its own workproduces
-
Signed activity Work eventsChat and code activityrecords
-
Audit trail Work recordOne searchable history
| Relay check | Shipped behavior | Result |
|---|---|---|
| Identity | Verifies event signature and signed-in key | Binds a signed event to one account |
| Member-only access | Closed workspaces and non-open channels check membership | Ordinary writes honor those rules |
Buzz binds each accepted event to the authenticated key and verifies its channel access.
A shared bot account can hide which agent changed a file. Buzz keeps each agent's events separate across chat and Git. If someone steals a key, an admin can remove its relay access without changing the owner's account.
The agent key does not change when its model or harness changes. Buzz should show those changes, or readers may assume the same software still runs it.
The controls are unfinished
| Control | Current state | Gap |
|---|---|---|
| Action rights | Channel membership controls access | No per-action approval |
| Human approval | Workflow creates an approval token | Cannot resume after approval |
Owner attestation remains a draft Nostr extension that records provenance. Relay membership controls access. Human approval uses a separate workflow step that cannot yet resume a run; Issue #2376 tracks the missing support.
Issue #2637 reports that the verifier rejects every audit chain stored in Postgres because Buzz hashes nanosecond timestamps while Postgres stores microseconds. Event signatures show authorship; the audit service cannot yet tell whether stored history changed.
Some work stays outside the event log
Buzz signs chat and Git events. Git objects live in another store, and voice frames never enter the event log. A reviewer can see which key announced a push or approved a change. Teams must check linked objects and later jobs elsewhere.
Models still lose context
Buzz keeps chat and agent work in one record. After a restart, an agent can search it, but the model still gets a limited prompt and a model-written summary. The relay may hold six months of chat; only selected messages enter the prompt.
| Control | What the code does | Limit |
|---|---|---|
| Prompt input | Channel mentions omit history; threads and DMs load 12 messages | Large messages can still fill the prompt |
| Recall | Loads core memory and offers full-text search | The agent must fetch notes or choose useful search words |
Buzz searches stored events with Postgres full-text search, which matches exact terms and may miss paraphrases. The agent must choose a query and inspect the results.
Buzz loads core memory only when a new ACP session starts. Named memories require a lookup, and a long session may keep an old core record. This lowers prompt use but can leave the agent with stale facts.
ACP prompts carry full event IDs and tags. The native agent resends saved history and tool schemas during tool calls. Its handoff replaces old history with a model-written summary; after ten handoffs, Buzz drops older turns.
Stored history helps only when an agent loads it.
When Buzz runs Codex or Claude Code through ACP, each runtime controls its own context and compaction. Buzz can track reported token use and add room history. The repository has no benchmark that compares token use with and without Buzz.
Issue #2631 says four configured agents spawned about 220 Codex processes and used 17.7 million tracked tokens. The reporter says Buzz pre-started too many agent processes. A bad pool setup can raise both process count and token use.
Live ACP sessions restart crashed agents
The ACP layer sends one prompt at a time per channel and batches later events. If an agent process crashes, Buzz starts a new one. These controls do not replay work missed while the agent was offline.
ACP replays events from about five seconds before startup, and its default mentions mode
accepts only tagged events.
Issue #1743
reports missed offline mentions; issue #2270
reports missed untagged thread replies.
Git review happens in chat
Buzz runs a Git server. Its Projects preview shows pull requests and review decisions. Teams can host Git without GitHub, while runners and security tools remain outside Buzz.
Issue #2469 says every signed-in member of a Buzz community can read each hosted repository, including projects tied to private channels. Channel roles limit pushes while reads remain open. PR #2539 adds private repository reads and remains unmerged.
One relay runs each community
Block calls Buzz decentralized because it uses Nostr keys and signed events. One relay holds each community's record; clients and relays do not copy events elsewhere. A team can run its own relay and reuse its keys on another server. Each community still depends on one operator for service and access.
Hosted messages and DMs lack end-to-end encryption. Block may read them or send them to outside model providers; by default, it keeps messages and media for up to 180 days.
A self-hosted team controls its relay. Remote model providers may still receive prompts. The team must also run four data stores and own upgrades and recovery.
Try one project room
| Trial | Use it when | Risk |
|---|---|---|
| Hosted | Two agents handle non-sensitive work | Block and model providers may read the work |
| Self-hosted | The team can run the relay and data stores | Model providers may still see prompts |
Wait when work needs working approval and offline delivery, or when code must stay private.
Run the same tasks in Buzz and one direct agent runtime. Hold the inputs and pass condition fixed, including the model and token limit. Count extra messages and rework. Stop if Buzz adds cost without cutting coordination work.
Low-risk work is the current limit
Pause a code-writing run for human approval, restart the relay service, then approve it. The run should resume once. Next, mention an offline agent and restart it; the saved work should arrive once. Both tests must pass before teams trust approval-gated delegation.
A private-channel member should clone its repository. A signed-in non-member should get the same response as a missing repository.
Buzz's strongest idea is the agent account: a key and work record that survive the model session. Keep merge rights and secrets outside Buzz until the approval restart, offline delivery, and private-repository tests pass.
block/buzz main at cfdea818 on July 24, 2026, after the
July 21 launch. Issues #1743, #2270, #2376, #2469, #2631, and #2637 were open; PR #2539 was open and
unmerged. Issue #2631 covers Desktop v0.4.23. I treat issue behavior as reported unless cited code confirms it.