Buzz Puts Your Agents in the Channel. Here Is What That Actually Changes.

Block shipped Buzz on 21 July. It looks like Slack, it is Apache-2.0 licensed, you can self-host it, and AI agents sit in channels as members rather than as bots you summon with a slash command.

The Slack comparison is what got the coverage and it is the least interesting thing about it. What is actually interesting is underneath: Buzz runs on Nostr, which means every participant, human or agent, is a keypair, and every message is a signed event on a relay you control.

That is a different architecture with different consequences, and a few of them matter regardless of whether you ever use Buzz.

Identity is the whole point

The reason agents in chat have been unsatisfying so far is that they had no real identity. A Slack bot is an app installation with a token. It posts as itself, it acts with whatever OAuth scopes the workspace granted, and when three teams each wire up their own automation, you get three bots that are indistinguishable in the audit log from any other integration.

In Buzz, an agent is a keypair. It signs its own messages. Its identity is cryptographic rather than an entry in a vendor's app directory, and it holds that identity across relays. When an agent says something in a channel, that statement is attributable in a way a webhook post is not.

This lands directly on a problem I keep writing about: most organisations cannot say how many agents they are running or what each one can reach, because agents arrived through a dozen different doors and none of them registered anywhere. A workspace where every agent must have a keypair to participate at all gives you a natural registry, because presence in the channel is the registration.

I would not overstate it. A keypair tells you who posted, not what that agent can do to your ERP. But it is a better starting point than a bot token in someone's app config.

The shared audit trail

The second consequence follows from the first. Humans and agents post into the same channels, and every message is a signed event on a relay you own.

That means the record of what an agent did, what it was asked, and what a human said in response is one continuous log in one place, and it is a log you hold rather than one a SaaS vendor holds on your behalf and exports on request.

For anyone thinking about oversight obligations, this is the shape you want. Not because a chat log is a compliance artefact on its own, but because the alternative most organisations have is an agent's actions in one system, the request that triggered it in another, and the human approval in a third, with no reliable way to join them.

There is a caveat worth naming. A conversation log is not a per-step execution trace. If your agent runs a twelve-step task, Buzz records that it was asked and what it reported, not what it did at step seven. You still need proper tracing underneath. What Buzz gives you is the human-facing half of the record, joined up, which is the half that usually goes missing.

How you actually get an agent in there

This is the part I found more encouraging than expected.

Buzz exposes its full surface programmatically. An agent can read channels, post messages, run workflows, manage repositories, and react to events without going anywhere near a GUI. The API is the product rather than an afterthought bolted onto a UI, which is unusual and clearly deliberate.

More usefully, there is a buzz-acp crate that exposes the same surface through the Agent Client Protocol. ACP is the emerging standard for connecting an agent harness to a host application, and it already works with Claude Code, Codex, and Goose. Nous Research shipped Hermes Agent integration in late July with three separate integration paths, preserving skills, long-term memory, approval workflows, and scheduled tasks over NIP-42 authenticated WebSockets across channels, DMs, and threads.

The practical upshot: you do not have to write a Buzz-specific agent. If your agent already speaks ACP, or runs in a harness that does, connecting it is configuration rather than a port. And if you later decide Buzz is not for you, the agent is not stranded, because ACP is the connector rather than a Buzz SDK.

That portability is the reason I would be willing to build a pilot on something pre-1.0. The investment is in your agent, not in Buzz.

What changes when agents are in the room

Having watched teams work with agents in a shared channel rather than through a private interface, a few things genuinely change, and one of them surprised me.

Work becomes reviewable by accident. When an agent posts its reasoning and its result into a channel, colleagues see it without anyone building a review process. Someone notices the agent used last quarter's pricing and says so. That correction happens in minutes and would otherwise have happened in a month, if at all.

Context accumulates in a place agents can read. The channel where people discuss a project becomes the context an agent working on that project can draw from. That is genuinely valuable and also the thing to be most careful about, because everything in that channel is now potential agent input, and agent input is attack surface. An agent that reads a channel a customer can post into is an agent reading attacker-controlled text.

And the third thing, which I did not expect: teams start talking to the agent in front of each other, which normalises correcting it. Agents used in private interfaces develop an odd authority, because nobody sees the times they were wrong. Agents in a shared channel get argued with, and that is much healthier.

Where it is not ready

Block calls it early stages. It is pre-1.0. TechCrunch's advice was not to port your team over yet and that seems right to me.

The specific things I would check before betting on it: relay operations are yours to run if you self-host, and running a reliable relay is a real operational commitment rather than a docker-compose afterthought. The desktop clients exist for macOS, Windows and Linux, and mobile is thinner. And the ecosystem of integrations that make a workspace tool actually usable, the calendar things, the ticketing things, the hundred small connectors, is at the beginning of its life rather than the middle.

There is also a question nobody has answered yet, which is what happens to a Nostr-based workspace at enterprise scale with enterprise retention and discovery requirements. The architecture is a good fit in principle, self-sovereign, signed, auditable. Whether the tooling for legal hold and retention policy exists is a different question, and today the answer is mostly not yet.

What I would take from it even if you never use it

Three ideas here are worth stealing regardless of the tool.

Give every agent a real, distinct identity, and make participation conditional on having one. Whether that is a keypair, a per-agent service principal, or a row in a registry, the property you want is that an agent cannot act anonymously or borrow another's identity.

Put the human-agent conversation in a shared, durable place rather than a private interface. The review effect is real and free.

And connect your agents through a protocol rather than a product SDK. ACP for the harness side, MCP for the tools side. That is what keeps this an experiment you can walk away from rather than a migration you have to justify.

Buzz is a bet that the workspace itself should be agent-native rather than a chat app with bots bolted on. I think that bet is probably right. Whether Buzz specifically is the thing that wins is a much more open question, and it is early enough that being interested without being committed is the sensible position.

We have been building agents that connect over ACP and MCP for exactly this reason, so the harness is a choice rather than a lock-in. If you are thinking about putting agents into your team's workspace and want it done so you can change your mind later, we should talk.