Buzz and the bot-token problem: what Block actually got right

On 21 July 2026, Block released Buzz: a free, open-source workspace where people and AI agents share the same channels, threads, calls, and repositories. It shipped under Apache 2.0, the desktop app runs on macOS, Windows and Linux, and the GitHub repository collected several thousand stars in its first week.

Almost every write-up framed it the same way — Jack Dorsey takes on Slack. That framing is accurate and mostly useless. Buzz is pre-1.0, the mobile clients are incomplete, and Block's own documentation sorts features into what works today, what is being wired up, and what is still unwritten. TechCrunch's advice was to not move your team over yet, and that is correct.

But underneath the launch story there is one engineering decision worth thinking about carefully, because it names a problem most teams running agents already have and have not looked at directly.

The problem nobody writes down

Here is what running agents in a normal workspace looks like today. You want Claude Code to open pull requests, so you create a bot user and give it a token. You want an agent to post deployment summaries, so it uses the same token, or a second one that nobody tracks. Someone adds a third automation on a Friday. Six months later the audit log says a change was made by deploy-bot, and deploy-bot is four different agents, a cron job, and an intern's script from March.

The authorship information is gone. Not corrupted — never captured. The token identifies the integration, not the actor. When something goes wrong and you need to answer "which agent did this, under whose authority, and what else did it touch on the same run", the log cannot tell you, because at the moment of writing it there was nothing to distinguish one caller from another.

This is fine while agents are answering questions. It stops being fine when agents write code, move money, message customers, or change infrastructure — which is roughly where a lot of teams are heading this year.

What Buzz does instead

In Buzz, every participant gets a Schnorr keypair. Not one per workspace, not one per integration — one per participant, human or agent. Each message, reaction, code review, git event and workflow step is a signed event, chained into a hash-linked audit log.

The consequence is small to state and large in practice: an agent signs its own work. It does not borrow your credentials to act. Its owner grants it a scoped authorisation, and from then on the record shows what the agent did, distinct from what its owner did.

That separates two things which normally arrive fused together:

• Authority — what an actor is permitted to do, granted and revocable by a human.
• Authorship — who actually performed a given action, established at the time it happened and verifiable afterwards.

Shared bot tokens collapse these into one. Buzz keeps them apart. Because the identity is a keypair the participant holds rather than a row in Block's database, it also travels: an agent's history stays verifiable on any Nostr-compatible system, and if Buzz disappears, the signed record does not stop being checkable.

Block is unusually direct about the motivation. Bradley Axen, its Head of AI Capabilities, framed the launch as a question of whether the place humans and agents work together ends up proprietary or open. Read the identity model as the concrete part of that argument. Portable identity is what makes "open" mean something more than a licence file.

Where the claim gets thinner

The launch language was "model-agnostic, decentralised, self-sovereign, and open source." Three of those hold up. The fourth needs qualifying, and it is worth being precise because the qualification is exactly the kind of thing a vendor evaluation should catch.

Model-agnostic is real: Buzz supports agents built on Claude Code, Codex, Block's own Goose, or something you wrote yourself. Nothing in the protocol cares which model is behind an agent's key. Open source is real — Apache 2.0, self-hostable, and you can read the relay code. Self-sovereign is real in the sense that matters: you hold your keys.

Decentralised is where it thins out. A Buzz workspace runs through a single relay. That relay authenticates users, verifies signatures, stores events and pushes updates to clients. There is no peer-to-peer exchange between relays, no gossip layer, no replication. Every read and write goes through one server. This came up repeatedly in the Hacker News thread, and the pushback holds up against Block's own documentation.

So what does "decentralised" actually buy you here? Self-hosting, plus identity that is not owned by the host. Those are worth having. They are not the same as a distributed network, and a team choosing infrastructure on the strength of the second word will be disappointed by the first.

There is a real security question too, raised in the same discussion and not yet settled by anything other than argument: an agent sitting in a channel can read everything in that channel. Scoped identities and a signed audit trail tell you afterwards what an agent saw and did. They do not, on their own, stop it from seeing something it should not have. Buzz's position is that scoped keys plus a complete trail beat a blanket bot token, which is true, and also not the same as a solved problem.

The part worth keeping

We think the identity model is the durable contribution, and it is separable from Buzz entirely. You do not need to adopt a pre-1.0 workspace to act on it. The question it raises applies to whatever you are running right now:

When an agent does something in your systems, does the record say which agent, acting under whose authority — or does it say bot?

If the answer is bot, that is a gap that gets more expensive as agents take on more consequential work, and it is cheap to close early. Three practical moves, in rough order of effort:

1. One credential per agent, never one per integration. Even without cryptographic identity, distinct tokens with distinct names restore the ability to attribute an action to an actor. This is a configuration change, not a project.
2. Record the grant, not just the action. Log which human authorised an agent to operate, over what scope, and when that grant expires. Most audit trails capture what happened and lose why the actor was allowed to do it.
3. Scope reads as carefully as writes. The channel-visibility problem in Buzz is the same one in your Slack workspace. An agent with read access to a general channel has read access to whatever anyone pastes into it, including things pasted in a hurry.

None of that requires Nostr, or Buzz, or a migration. It requires deciding that agents are actors in your system rather than features of it, and treating their identity accordingly.

Our read

Buzz is early, and the Slack-replacement framing is the wrong reason to look at it. Do not move a team onto it this quarter. Do install it on one machine, run an agent in a channel, and look at what the signed event log records — an hour spent there is a better education in agent accountability than a week of reading about it.

The idea it is carrying is one the rest of the industry will need regardless of whether Block's workspace succeeds. Once agents are colleagues rather than scripts, they need to be identifiable as such — with their own name on their own work, their permissions granted deliberately, and a record that still means something six months later. Block built a workspace around that premise. The premise is the part worth taking.

---

If you are putting agents into real workflows and want a senior read on identity, permissions, and what the audit trail needs to capture before it matters, that is the kind of thing we help with at Think and Form Limited. Get in touch at admin@thinkandform.co.nz.