Block's Buzz: a Nostr workspace where agents get their own cryptographic identity

Block released Buzz on July 21, and the detail that made me stop scrolling was not the Jack Dorsey byline. It was that every AI agent in a Buzz workspace has its own cryptographic identity. Buzz is an open-source workspace, Apache 2.0, built on the Nostr protocol, where humans and agents share channels and repositories. It is model-agnostic: Claude Code, OpenAI Codex, and Block's own Goose all plug in. It lives at buzz.xyz and on GitHub. Most of the industry is still arguing about how to log which agent did what. Block shipped a workspace where that question is answered by a signature.

What shipped

• Shared channels and repositories where people and agents post, discuss, and commit side by side.
• Per-agent cryptographic identity. On Nostr an identity is a keypair and every event is signed by it, so an agent's messages and commits are attributable to a specific key, not to a shared service account.
• Model-agnostic runtime. Claude Code, Codex, and Goose are the named integrations; if you already run Goose recipes, that is the shortest path to trying it.
• Open source under Apache 2.0, with the code on GitHub and the hosted entry point at buzz.xyz.

The pitch on the collaboration side is consolidation: one place instead of three or four SaaS tools stitched together for chat, code, and agent runs. That is nice. The identity part is the interesting engineering.

Why identity is the part that matters

In a typical MCP-centric stack, the agent is a process holding a bundle of tokens: a GitHub token, a database credential, a model API key. Every action shows up in logs as that token's owner, usually the human who set it up or a bot account shared by the team. When something goes wrong you get "the deploy bot did it," which is not attribution, it is a shrug. The MCP primer covers why the protocol itself does not solve this: MCP standardizes how tools are called, not who is calling.

Nostr flips the default. The agent's key is the identity. Its messages in a channel and its commits in a repository are signed events, so you can answer "which agent, on which run, said this" without trusting a log line that any process holding the token could have written. Revoking an agent means dropping its key from the workspace, not rotating a secret that six other things depend on.

If your agents share a service account, your audit log is a story you tell yourself, not a record of what happened.

Where it is not production-ready

I want to be precise about what the July 21 release does and does not establish, because the material I worked from is a launch announcement, not an architecture review.

• Permissions are not the same as identity. Knowing which key committed does not tell you whether that key was allowed to. Buzz's authorization model is not described in the launch coverage, so assume you are building policy on top.
• Nostr is a relay network. Where your workspace events live, who can read them, and how you keep proprietary code off public relays are deployment questions the announcement does not answer.
• Key custody for agents is an unsolved operational problem everywhere. A private key on a box that also runs an autonomous agent with shell access is exactly the credential that gets exfiltrated.
• It is day-one software. Apache 2.0 and a GitHub repository are an invitation to read the code, not evidence it has survived a hostile tenant.

What I would do with it this quarter

Run it as a sandbox for one internal team with one agent, and treat it as a design reference more than a platform bet. The thing to steal, even if you never adopt Buzz, is the principle: one key per agent, every action signed, revocation by key. You can approximate that today with per-agent service identities and signed commits. Buzz just makes the shape of the answer obvious.

The honest gap

Everything above about Nostr's signing model is protocol-level knowledge, not something I verified inside Buzz's own implementation, and Block has not published security guarantees, throughput numbers, or a threat model that I could find in the launch coverage. Until those exist, this is an interesting proof that agent identity can be a first-class primitive, not a place to put your production agents.