Buzz Gives AI Agents Their Own Keys, Not Just a Bot Account

Block's open-source workspace puts humans and agents in the same rooms with the same audit trail, built on Nostr signed events. The design is elegant. The thing still being wired up is the part that would keep it safe.

Most "AI in your workspace" tools are a bot account bolted onto Slack. The bot answers when you @-mention it, posts a summary, and otherwise sits there like a vending machine. Buzz, the open-source project from Block, throws that model out. In Buzz an agent is not a bot. It is a member. It has its own cryptographic keypair, its own channel memberships, its own audit trail, and the same surface area as a human teammate: open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into a voice huddle, create a channel.

The README puts it plainly: "Agents are colleagues, not haunted cron jobs." That is a genuinely different bet than everyone else is making, and it is worth understanding both why it is clever and where it gets scary.

One log, one identity model, one search index

Here is the mechanism, because the mechanism is the whole idea. Buzz is a Nostr relay. Nostr is a protocol where every action is a signed event: you have a keypair, and everything you do (post a message, react, approve a review, land a git patch) becomes an event signed by your key and written to one append-only log.

Buzz takes that and runs the entire workspace on it. A chat message is a signed event. A code patch is a signed event (using NIP-34, the Nostr standard for git). A CI result, a workflow step, a review approval: all signed events in the same log, from the same kind of key, whether a person or a process authored them. The relay is the single source of truth. Postgres holds the events, Redis handles presence and typing, Typesense does search, S3 or MinIO holds media.

The payoff is a thing the README calls "the weirdly powerful thing," and the phrase is fair. One relay does what teams currently fake with a chat app, a git forge, a pile of bots, a CI dashboard, a release tool, and glue code holding them together. Because the conversation, the patch, the workflow run, and the approval are all the same kind of event, you can search across all of them at once. Ask the project "have we seen this error before?" and an agent watching the channel can pull six months of history, post the threads and the root causes, and offer to page whoever shipped the last fix. Question, answer, and evidence all stay in the room, all signed, all searchable.

That is a real reframe of what multi-agent coordination even is. The industry has mostly been building orchestration harnesses: a controller process that spawns workers, routes tasks, and collects results. Buzz says coordination is a communication problem, not an orchestration problem. Put every actor on one signed-event bus, give each a key, and let them talk. The harness is not a program on top of the agents. It is the shared log they all write to.

Scoped by identity, not by permission flags

The part I find most thoughtful is how Buzz handles what an agent is allowed to do. The README again: agents are "scoped by identity, not by permission flags, the same way you'd scope a teammate."

Think about how you actually limit a human coworker. You do not give them a giant permissions matrix. You add them to the channels they need, and not the ones they do not. Their access is a function of who they are and which rooms they are in. Buzz applies the same logic to agents. An agent triaging a bug gets its own key and membership in the channels relevant to that bug. It does not get "the keys to the kingdom," because it was never added to the kingdom's channel.

This is cleaner than the permission-flag approach it replaces, and I think it is right. Identity-based scoping matches how trust actually works on a team. It also produces an audit trail for free, because every action the agent takes is already a signed event under its own key. You can always answer "which agent did this, and when," which is more than most bot integrations can say.

The catch is that a key is a bearer credential

Now the scary part, and it falls straight out of the elegant part.

Giving an agent the same surface area as a human teammate means giving it a human teammate's blast radius. A Buzz agent can open repos, send patches, orchestrate other agents, and (through the buzz-dev-mcp crate) run shell and file-edit tools. That is not a summarizer. That is production access wearing a friendly persona. If that agent is prompt-injected, or simply misfires on an ambiguous instruction, the damage it can do is the damage a compromised teammate could do, and it can do it at machine speed across every channel it belongs to.

Identity-scoping helps, but a keypair is a bearer credential. Whoever holds the key is the agent, and agent keys have to live somewhere a process can read them (BUZZ_PRIVATE_KEY is an environment variable in the setup docs). The signed-event audit log is excellent for telling you what happened. It is a record, not a gate. It tells you the agent shipped a bad patch after the patch shipped.

The gate you would want is an approval step: the agent proposes, a human signs off, then it acts. Buzz knows this. It is in the plan. And it is in the wrong column of their own readiness table.

Read their own status table honestly

Block deserves credit for one of the more honest READMEs I have read. It ships a three-column table: "Works today," "Being wired up," and "Strong opinions, pending code." No marketing gradient, just where things actually stand.

What works today: the relay, channels, threads, DMs, canvases, media, search, and the audit log. The desktop app (Tauri and React). The agent-first buzz-cli (JSON in, JSON out, built for LLM tool calls) and the ACP harness that connects Goose, Codex, and Claude Code. YAML workflows with message, reaction, schedule, and webhook triggers. Git events over NIP-34.

What is still "being wired up": the git hosting backend, the mobile clients, and, right there in the middle column, "workflow approval gates (infra exists, glue still drying)."

That last one is the whole safety story, and it is not done. The mechanism that would let you say "the agent can propose a merge but a human approves it" is infrastructure-present and glue-pending. So today you get the full agent surface area (write patches, run shell, orchestrate other agents) and the approval gate that would bound it is the part still drying. The README even warns you not to "plan your compliance program around" the aspirational column yet. Take them at their word.

Put this into practice

If you want to try Buzz without handing an agent more than you meant to, here is the sane path.

Self-host the relay first, and keep it local. The quick start needs Docker and either Hermit or a Rust 1.88+, Node 24+, pnpm toolchain. You clone, run just setup && just build, then just relay in one terminal and just dev in another. The relay comes up on ws://localhost:3000 and the desktop app opens. Do this on your own machine before you point it at anything shared. Owning the relay is the entire premise ("a relay you own"), so use that.
Give your first agent a key with almost nothing attached to it. An agent's power is its channel memberships. Create a throwaway channel, add the agent's key only to that, and let it do something low-stakes: answer questions, search history, draft a message. Do not add it to a channel wired to a real repo until you have watched it behave.
Treat buzz-dev-mcp shell access as production access, because it is. The dev MCP crate gives an agent shell and file-edit tools. That is the highest-authority thing in the box. Do not enable it for an agent you would not hand your terminal to, and never on a shared or production host.
Do not wait on the approval gates. Since workflow approval gates are still being wired up, build the gate yourself the old-fashioned way: keep agents on proposals, not merges, and make a human the one who lands anything irreversible. Use the audit log to review what agents did, daily, like reading a teammate's PRs.
Pin your version and read the changelog. This is a fast-moving pre-1.0 project (51 releases already, latest desktop build tagged in the 0.4 range). Pin to a release, and re-read the readiness table each time you upgrade, because the column an item lives in is the only thing that tells you whether the safety piece landed.

Honest limitations

Start with the numbers, because the trending boards oversell this one. Buzz was the top AI-agent repo on at least one momentum board this week, which sounds like broad adoption. The actual GitHub counts are 116 stars, 20 forks, and 3 watchers against 863 commits. That is a serious, actively built codebase with a small real audience, not a widely deployed platform. Momentum rank measures attention velocity, not how many people run the thing. Do not mistake "trending" for "proven."

It is also genuinely unfinished, and Block says so: "Not finished. We will tell you what works and what doesn't." Mobile clients, git hosting, and the approval gates are all in flight. If you need those today, you are building on a promise.

The Nostr foundation is a real bet with real edges. Signed events give you the audit trail and the one-log elegance, but Nostr's relay-and-key model is younger and less understood than the boring auth stacks most teams run, and "web-of-trust reputation across relays" sits in the pending-code column. And Block is a company; an Apache-2.0 license means you can self-host and fork, but the roadmap and the center of gravity are theirs. If they lose interest, you own a large Rust workspace and the maintenance that comes with it.

What now

The idea underneath Buzz is more durable than this particular implementation, and that is the thing worth watching. If the coordination layer for multi-agent work really is a shared signed-event log rather than a stack of orchestration harnesses, then the interesting fights of the next year are about identity, scoping, and the approval gate, not about which framework spawns workers fastest. Buzz has the identity and the scoping. It is missing the gate, and it is honest that it is missing the gate.

So the question I would sit with is this: are you comfortable with a design where the agent has a full teammate's reach and the "wait, let a human approve that" step is the newest, least-finished part? For a throwaway channel on your laptop, sure. For anything that can touch a real repo, I would want that middle column to move left first.

If you have run Buzz with agents wired to an actual codebase, I want to know what you scoped their keys to, and what you wish you had scoped tighter.

Sources: block/buzz on GitHub (README, architecture, and readiness table); Buzz Nostr notes; Block, Inc.. Star, fork, commit, and release counts read from the GitHub repository page on July 22, 2026, and differ from the project's trending-board momentum rank.