Block Buzz: The AI Agent Workspace Where Agents Are Teammates, Not Bots

Block Buzz: The AI Agent Workspace Where Agents Are Teammates, Not Bots

Most "AI in your chat" setups work the same way: you bolt a bot onto Slack or Discord, give it a slash command, and it answers when summoned. The bot lives outside the team. It has a separate identity, a separate audit trail, and a hard ceiling on what it can touch. Block looked at that pattern and decided the agent should just be a member of the room.

That idea is Buzz, an open-source workspace from Block, Inc. that has already drawn around 18,000 GitHub stars. In Buzz, humans and AI agents share the same channels, sign their actions with the same kind of cryptographic key, and end up in the same searchable log. It's written in Rust and licensed Apache 2.0. I spent time reading through the repo's architecture docs so you don't have to, and the design choices are more interesting than the marketing suggests.

What Is Block Buzz?

Buzz is a self-hostable workspace from Block, Inc. where humans and AI agents share the same channels. It runs on a Nostr relay, so every message, reaction, code patch, approval, and workflow step is one signed event in a single, searchable, tamper-evident log. It's open source under Apache 2.0, built in Rust, and you run the relay yourself.

Key takeaways:

• Agents are first-class members with their own keys and audit trail, not bots bolted on the side.
• Everything (chat, patches, CI, approvals) is one signed Nostr event in a single searchable log.
• Agents plug in through ACP and MCP, so Goose, Codex, and Claude Code work out of the box.
• Self-hosted and open source (Apache 2.0), with an honest, public list of what's not done yet.

The phrase the project leans on is "a hive mind communication platform." That sounds grand, but the day-to-day reality is simpler: it feels like a team workspace. Channels, threads, DMs, a canvas, voice huddles, search. The twist is what's underneath. Every action is a signed Nostr event, and the author of that event can be a person or a process. Same shape, same identity model, same audit trail either way.

If you've been comparing agent frameworks like LangGraph, CrewAI, and the OpenAI Agents SDK, Buzz is a different layer entirely. Those are libraries you embed in code to orchestrate an agent's reasoning. Buzz is the room where the agent and your team talk, hand off work, and leave a record. They're complementary, not competitors.

Why "Agents as Members" Changes the Model

The bot model has a structural problem: the agent is a guest. You grant it permission flags, it operates through a narrow API, and when something goes wrong you're reconciling two separate histories, the team's chat and the bot's logs.

Buzz flips this. An agent gets its own keypair, its own channel memberships, and its own audit trail. You add an agent to a channel the same way you add a person. The project describes the scoping as "by identity, not by permission flags," which is the same way you'd scope a human teammate. You trust them in some rooms and not others.

Once an agent is a member, it gets the same affordances everyone else has. It can open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, create channels, and drop into voice huddles. The README walks through three scenarios that make this concrete:

• Incident memory. It's 2am, you ask "have we seen this error before?", and an agent watching the channel pulls six months of history, posts the threads and root causes, and offers to page whoever shipped the last fix. The whole exchange stays in the channel as evidence.
• Branch as room. You open a feature branch and a channel appears. Patches land as events, CI posts results, an agent runs a first-pass review, and the merge decision lives in the same room as the evidence that justified it.
• A release that writes itself. A workflow fires on a tag, an agent drafts release notes from the merged PRs, posts them for human review, gets a thumbs-up reaction, and ships. Every step signed, every step searchable.

The common thread is that the conversation, the code, and the decision all live in one place instead of seven tabs pretending to know about each other.

How Agents Actually Plug In: ACP and MCP

This is where the engineering gets clean. Buzz ships two small binaries for agents, and they deliberately don't know about each other.

buzz-agent is an ACP agent. It speaks the Agent Client Protocol over stdio, calls an LLM, and uses MCP tools. It runs up to eight concurrent sessions, each with its own MCP servers, history, and context. When a session's context fills up, it summarizes its own history and keeps going. It works with Zed, JetBrains, or anything else that speaks ACP.

buzz-dev-mcp is an MCP server. It gives any agent a shell and a file editor. Processes are ephemeral with process-group kill on every exit path, output is bounded, and file edits resolve against the working directory. If you've built with the Model Context Protocol before, this will feel familiar: it's the standard "give an agent hands" pattern, hardened.

The design note in the repo puts it bluntly: "two binaries, two protocols, no coupling between them." The agent doesn't know which MCP server it talks to, and the MCP server doesn't know which agent calls it. They compose through protocols, not imports. The practical payoff is that you can run ten agents behind Buzz with different MCP configurations, or swap your LLM provider with one environment variable.

Because buzz-acp bridges relay @mentions to agent subprocesses, you can point it at Goose, Codex, or Claude Code. If you're already running background coding agents, Buzz gives them a shared room to operate in rather than a silent headless loop. And if you want to bring your own tools, building an MCP server is the supported path, with plenty of ready-made MCP servers to start from.

Under the Hood: The Architecture

Buzz is a Rust monorepo, and the single most important fact is this: the relay is the single source of truth. There's no peer-to-peer gossip and no replication. Clients connect to one relay over WebSocket, and the relay handles auth, verifies signatures, persists events, fans them out to subscribers, indexes them for search, and triggers automation.

Everything is a Nostr NIP-01 event. Each event has six fields: an id (SHA-256 of the serialized event), a pubkey, a kind integer, tags, content, and a Schnorr signature. The kind integer is the only dispatch switch. Want a new feature? Define a new kind number. Existing clients see nothing and break nothing. The codebase defines 81 kinds, with custom Buzz kinds living in the 40000-49999 range.

The supporting stack is deliberately boring, in the best way:

Postgres holds the events and runs full-text search. Redis handles pub/sub fan-out, presence, and typing. S3-compatible object storage (MinIO locally) holds media via the Blossom protocol.

The security model is where I stopped skimming. Every event has its Schnorr signature and SHA-256 ID verified before storage. NIP-42 auth uses a ±60 second timestamp tolerance to block replay attacks, and auth events are never stored or audited. The audit log is a genuine hash chain: each entry's SHA-256 covers every field including the previous hash, so tampering with one entry breaks every entry after it. Outbound webhooks get SSRF protection that checks for private IP ranges. And channel membership is the only access gate, enforced at every operation, with the subscription handler checking access before it registers a subscription so there's no race window for private-channel leaks.

If you're evaluating how to deploy agentic AI on infrastructure you control, this is the part worth reading twice.

What Works Today (and What Doesn't)

The project is unusually honest about its own status, and I think that honesty is the strongest signal of a serious codebase. Here's the current state straight from the repo:

Now the part most product posts skip. The architecture doc lists verified gaps, not aspirations:

• No rate limiting is enforced yet. The RateLimiter trait exists and four tiers are designed (human, agent-standard, agent-elevated, agent-platform), but the only implementation is a test stub.
• Approval gates aren't wired end-to-end. The executor can suspend a run, but a workflow that hits an approval gate currently gets marked as failed.
• Some workflow actions are stubbed. send_dm and set_channel_topic return "not implemented," so a run that reaches one fails.
• Huddle recording and per-track publishing aren't built. Voice rooms and join/leave lifecycle work; recording has reserved event kinds but no producer.
• No sqlx offline query cache. Queries run at runtime rather than being validated at compile time.

None of this is disqualifying for a self-hosted tool you're evaluating, but it tells you exactly where the edges are. If you need to evaluate agents in production with hard guarantees, treat the 💭 and 🚧 columns as load-bearing warnings.

Getting Started with Buzz

There are three paths, depending on who you are.

Just want to try it? Grab a packaged build from the latest release: macOS (.dmg), Linux (.AppImage or .deb), or Windows (.exe). By default it connects to ws://localhost:3000, so you'll still want a relay running.

Want to build from source? You need Docker and either Hermit or Rust 1.88+, Node 24+, pnpm 10+, and just. Then:

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit
just setup && just build

# every day:
. ./bin/activate-hermit
just dev   # starts the relay + desktop app together

The relay lands on ws://localhost:3000 and the desktop app pops up. For a single-node VPS deployment instead of the local-dev stack, there's a production Compose bundle under deploy/compose/ with Postgres, Redis, MinIO, and optional Caddy for TLS.

Bringing an agent? Set BUZZ_PRIVATE_KEY and use buzz-cli, which is JSON in and JSON out, designed specifically for LLM tool calls. That's the seam where your agent workflows connect.

Who Should Run Buzz?

Buzz is for teams that want one substrate instead of a pile of glue code. If your current setup is chat plus a forge plus bots plus CI dashboards plus release tools plus a search index, and you're tired of them not knowing about each other, this is the bet Buzz is making: one community, one identity model, one event log.

It's a strong fit for:

• Self-hosters who want their agent traffic on infrastructure they own, with an audit trail they can verify.
• Platform engineers evaluating agent-first workflows where agents triage bugs, run reviews, and draft releases as members rather than scripts.
• Open-source evaluators who want to read the whole thing in an afternoon. The agent surface is two crates with no coupling, deliberately small enough to audit.

It's not yet for people who want a finished, batteries-included SaaS you can hand to a non-technical team tomorrow. The approval gates, rate limiting, and mobile clients are still landing. Buzz tells you this plainly, which is exactly why I'd trust it with a careful pilot.

The framing I keep coming back to is in the README: "Agents are part of the room, not haunted cron jobs." If you've ever debugged a bot at 2am with no idea what it did or why, you already know why that matters.

FAQ

Is Buzz free and open source?

Yes. Buzz is open source under the Apache 2.0 license and built by Block, Inc. You self-host the relay yourself, so there's no per-seat fee for the software. Your costs are your own infrastructure: a server for the relay, Postgres, Redis, and object storage. The source, issues, and roadmap are all public on GitHub at block/buzz.

How is Buzz different from Slack with bots?

In Slack, an agent is a second-class bot with a separate identity and audit trail, scoped by permission flags. In Buzz, an agent is a first-class member with its own keypair, channel memberships, and the same affordances as a human: opening repos, sending patches, running workflows, joining huddles. Everything lands in one signed, searchable event log.

What are ACP and MCP?

ACP is the Agent Client Protocol, the stdio interface buzz-agent uses to talk to an LLM client like Zed. MCP is the Model Context Protocol, the interface buzz-dev-mcp uses to give an agent a shell and file editor. The two binaries don't know about each other; they compose through protocols, so you can mix agents and tool servers freely.

Does Buzz use blockchain?

No, and the README is pointed about it: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz uses Nostr's cryptographic signatures and a hash-chain audit log for tamper evidence, but there's no token, no chain, and no consensus mechanism. You get verifiable history without the overhead.

Can I use my own AI agents, like Goose, Codex, or Claude Code?

Yes. The buzz-acp harness spawns AI agent subprocesses and bridges relay @mentions to them over ACP. It supports Goose, Codex, and Claude Code out of the box, runs a pool of one to 32 agent processes, and respawns an agent if it crashes. For custom tools, you connect your own MCP server.

Is Buzz production-ready?

Parts are. The relay, channels, search, audit log, desktop app, and agent CLI work today. But rate limiting isn't enforced, approval gates aren't wired end-to-end, and mobile clients are still in progress. For a self-hosted pilot with a team that tolerates rough edges, it's ready to try. For a compliance-critical deployment, wait for the 🚧 items to land.