Dora NodaOn July 21, 2026, Jack Dorsey announced Buzz — Block's open-source workspace where humans and AI agents share the same channels, repos, and workflows — as "model-agnostic, decentralized, self-sovereign, and open source," built to reduce Block's own dependency on Slack and GitHub. Within days it sat at #1 on GitHub trending, and by late August the repo had passed 30,000 stars. The pitch is seductive for any team running agents: one room where people, Claude Code, Codex, and goose all work together, every message and patch a signed event on a Nostr relay you can self-host.
Here is the verdict up front, because the hype cycle will not give it to you: Buzz solves agent coordination, not agent operations. It answers "how do humans and agents stay in sync" brilliantly, and it does not attempt "how does an agent safely change production." Those are two different layers, and a deploy-from-chat platform needs both:
| Capability | Buzz (Nostr workspace) | MCP deploy surface |
|---|---|---|
| Shared human/agent context | Yes — one room, persistent threads | No — per-session tool calls, no memory |
| Agent identity across harness swaps | Yes — portable Nostr keypairs | Varies — usually vendor accounts or API keys |
| Human-in-the-loop approvals | Yes by default — approvals land in a channel people read | Must be built — gated tools, approval flows |
| Typed tool contract | No — chat messages, not schemas | Yes — JSON-RPC tools with input schemas |
| Per-action scoped permissions | No — channel membership is the unit | Yes — per-tool scopes, read/write splits |
| Production audit trail | Conversation log ("what did it say") | Action log ("what did it change, with what rollback") |
The rest of this post earns each row: what Buzz actually is, the three coordination problems it solves that MCP never attempted, the three deploy-surface guarantees it skips, and the two-layer stack the comparison points to.
What Buzz actually is
Buzz is a collaboration workspace built on the Nostr protocol, released by Block on July 21, 2026 under Apache-2.0 at github.com/block/buzz, with its home at buzz.xyz. The surface area is deliberately familiar: channels, threads, direct messages, voice, media sharing, code repositories, and automated workflows. Slack crossed with GitHub is the comparison every writeup reaches for, and Block invites it — Dorsey framed the launch as reducing dependence on exactly those two products.
The agent story is what makes it more than a chat clone. Agents in Buzz are not bots responding to slash commands. Each agent holds its own cryptographic keypair, has defined permissions, and participates as a first-class member: posting, reviewing code, running approved automations, joining threads. The platform is model-agnostic and harness-agnostic — Claude Code, Codex, goose, or anything speaking the Agent Client Protocol (ACP, JSON-RPC over stdio) can join a project, and Block's promise is that an agent keeps its identity, permissions, and history intact across a model or harness swap.
As Bradley Axen, Block's Head of AI Capabilities, put it at launch: "Every company is going to need a place where humans and agents work together. The question is whether that place is proprietary or open."
Two properties matter most for self-hosters. First, identity is portable by construction: a Nostr keypair belongs to the participant, not to the platform, so an agent's history and reputation travel with it to any Nostr-compatible system. Second, everything — messages, patches, CI results, reviews, approvals — is a signed event on a relay the team can run itself, with Block's managed relay as the alternative. Full control over data, relay, and agents, or managed infrastructure with the same protocol guarantees.
The honest caveats: Buzz is pre-1.0 (v0.4.x at launch), desktop clients for macOS, Windows, and Linux shipped first, mobile apps are still landing, and TechCrunch's launch-day advice holds — ripping out a working Slack org on day one is bravado, not a migration plan. But the core idea is what multi-agent teams have been bolting together ad hoc for two years: one room, one identity model, agents that are not second-class bots.
What Buzz gets right: three coordination problems MCP never attempted
An MCP server gives an agent tools to call. It does not give a team of agents — plus the humans nominally in charge — a shared understanding of what is going on. That gap is Buzz's entire product, and it solves it with three mechanisms worth naming precisely, because each replaces something teams currently hand-roll.
Persistent shared context in one room. Every MCP tool call is stateless: the agent calls deploy, gets a result, and whatever it learned lives in that session's context window until it scrolls away. When three agents and two humans coordinate a release across tool calls, the shared state is whichever chat thread someone remembered to update. Buzz inverts this — the room is the state. Threads, patches, CI results, and approvals accumulate in one searchable place that every participant, human or agent, reads from.
Nothing about MCP competes with this because MCP never tried to be a memory layer; the ecosystem's answer has been external stores and prompt stuffing, both of which rot. A signed event log on a relay you own is the first credible default for "where did we leave this."
Portable identity that survives a harness swap. Today an agent's identity is usually a vendor API key or a platform account: swap from one harness to another and you re-provision credentials, re-grant permissions, and lose the history tied to the old account. Buzz agents hold Nostr keypairs, so the identity is cryptographic and portable — the same key, permissions, and history whether the thing behind it is Claude Code, Codex, goose, or a harness that does not exist yet. This is the same neutrality argument the industry just accepted for protocols (MCP under the Agentic AI Foundation, A2A under the Linux Foundation), extended down to the agent itself. Teams that have ever migrated a bot between platforms know the re-provisioning tax; Buzz prices it at zero.
Human-in-the-loop by default, not by integration. The enterprise MCP consensus in 2026 is that destructive actions need mandatory human approval — but the approval has to live somewhere, and "somewhere" usually means a separate dashboard, a PagerDuty ack, or a Slack webhook somebody wired up. Buzz's approvals land in the channel the team already reads, next to the thread that proposed the action, from an agent whose identity and history are visible in the same window. The review surface is not an integration; it is the product. That is a genuine safety-property upgrade over approve-by-webhook, because the context the human needs to decide is adjacent to the decision, not three tabs away.
What Buzz skips: three things a deploy surface still needs
Now the other side of the table. Everything above is about coordinating decisions. None of it executes a decision against production with the guarantees production requires. A deploy-from-chat platform that mistook the room for the deploy path would discover three gaps, each tied to a concrete failure mode.
Chat messages are not a typed tool contract. When an agent says "deploy the auth service" in a Buzz channel, that is prose — no schema, no required fields, no validation that the ref exists or the environment is healthy. An MCP deploy tool like app.deploy takes typed parameters (service, ref, environment, idempotency key) and returns typed errors (REF_UNKNOWN, ENV_DEGRADED, ROLLOUT_TIMEOUT) the caller can branch on. The difference shows up at 2 a.m.: prose deploys fail ambiguously and retry blindly, while typed tools fail with codes a runbook can handle — roll back on timeout, page on degraded, stop on unknown ref. Buzz wisely does not invent a tool-call format; but that means the room cannot be the thing that validates "deploy this" before it happens.
Channel membership is not per-action scoped permission. Buzz permissions answer "who is in this room and what can they do here" — the right unit for collaboration, the wrong unit for operations. Production needs the AWS-MCP-server split: the credential behind logs.tail and app.status must be incapable of calling app.deploy, so read tools can go to every agent while write tools go to a gated few. Channel membership cannot express "this agent may read production logs but may not restart production," because membership is coarse and conversational while action authority must be fine-grained and enforced at the tool boundary. The 2026 enterprise playbook — per-agent tool allowlists, OAuth-bound scoped identity, a gateway that is the single choke point — exists precisely because coarse identity plus powerful tools is how agents get the "lethal trifecta" of data, credentials, and autonomy in one place.
A conversation log is not a production audit trail. Buzz's signed event log is excellent evidence of what the agent said: the proposal, the discussion, the approval. An incident review needs what the agent changed: which ref went live on which machines at what time, under which credential scope, with which rollback executed or available. Those are different records with different schemas, retention rules, and consumers — one serves the team, the other serves compliance and the 3 a.m. rollback decision. Deriving "what changed in prod" by re-reading a chat thread is forensics, not operations. The deploy surface must emit its own action log, keyed by deployment id and machine-readable rollout state, whether or not the conversation that authorized it lives in Buzz.
None of these gaps is a criticism of Buzz's design. A typed tool contract, per-action scopes, and a deployment ledger would each complicate the product Block actually shipped — and "Slack crossed with GitHub for humans and agents" is already an ambitious v0.4. The gaps matter only if you confuse the layers.
Run both layers: the stack this comparison points to
The comparison resolves into a concrete architecture, not a choice. Run the room for coordination and the tool surface for operations, with a crisp boundary between them:
- Buzz (or its protocol equivalents) owns the conversation. Agents propose, humans approve, history accumulates — all on a self-hosted relay, all under portable identities. When the harness behind an agent changes next quarter, the room does not care.
- A scoped MCP surface owns production authority.
app.statusandlogs.tailare readable broadly;app.deployandapp.rollbackrequire narrow scopes plus the human approval that happened in the room. Tools validate, scope credentials, emit typed errors, and write the deployment ledger. - The approval in the room gates the tool call, but never substitutes for it. The agent that got a thumbs-up in chat still calls a typed tool with a scoped credential — the chat message authorizes, the tool contract executes. Either layer alone is half a system: the room without tools can only talk about deploys, and the tools without the room are powerful endpoints with no shared memory of why they were called.
For a self-hosted PaaS, this division is good news twice over. Both layers are open and self-hostable — the relay on your machines, the MCP server in front of your fleet — which means the whole agent-operations story runs on infrastructure you own, with no third party in the path between "the agent proposed it" and "the fleet did it." And the boundary between layers is where your platform's real value lives: anyone can run a chat room, but only the platform can turn an approved proposal into a validated, scoped, auditable change to running services.
The bottom line
Buzz earned its trending spot by naming the layer the agent ecosystem was missing: shared, portable, human-readable coordination for teams of people and agents. The teams that get the most from it will be the ones that also name the layer it is not — the governed tool surface where proposals become production changes with schemas, scopes, and ledgers. Watch Buzz for the room; build the deploy surface yourself; keep the boundary between them explicit. The next two years of agent infrastructure will be won by platforms that run both layers well, not by either layer trying to absorb the other.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. A scoped, auditable MCP surface for deploy and rollback is exactly the operations layer this stack needs, and it is the direction bex is heading. Star the repo on GitHub or deploy your first app today.
