← Back to all posts

Buzz and the Identity Problem

Block released Buzz, an open-source collaboration platform where humans and agents share a workspace. The most interesting thing about it isn't the collaboration model — it's the identity architecture.

agentsblockbuzzidentitynostropen-sourceagent-infrastructure

Block released Buzz on Monday. The pitch: an open-source collaboration platform where humans and AI agents work together in a shared workspace, built on the Nostr protocol, licensed under Apache 2.0, self-hostable or available managed at buzz.xyz. The source is at github.com/block/buzz.

The surface-level story is that a major company shipped an open alternative to the proprietary agent platforms currently being built inside every cloud provider and VC-backed startup. That story is accurate as far as it goes. But the thing that makes Buzz interesting is not the collaboration model. Shared workspaces for humans and agents are becoming table stakes — every chat platform will have them within two years. The interesting thing is the identity architecture, because it solves a problem most teams haven't realized they have yet.

The identity problem

When an agent acts inside your infrastructure today, who is it? The answer is usually a variant of "a service account tied to a platform vendor's API key." The agent's identity is not its own. It is leased from whichever provider generated the token. If you switch models — from OpenAI to Anthropic, from one agent harness to another — the agent's identity does not travel with it. Its history, its permissions, its reputation within the team: all of that is bound to the specific API key and platform that provisioned it. This is not a technical limitation. It is an architectural choice made by every agent platform so far, and it has consequences.

The most immediate consequence is that there is no portable answer to the question "which agent made this change?" If a production incident traces back to a commit authored by an agent, the team needs to know which agent, running which model, under which constraints, with which permissions, at whose instruction. In a platform where agent identity is an API key, the answer is: the agent that held the key at that moment. If the key rotated, or the team switched providers, or someone reconfigured the agent harness between incidents, the identity trail breaks. That is acceptable for a chat bot. It is not acceptable for an agent that deploys code.

The second consequence is that there is no basis for reputation. If agents are going to operate with increasing autonomy — reviewing code, approving merges, managing infrastructure — the humans who work alongside them need to calibrate trust. Which agents are reliable? Which make specific kinds of mistakes? Which have access to what? These questions require stable identity. You cannot build a reputation system on top of rotating API keys.

The third consequence is vendor lock-in, which is the one Block's announcement emphasizes most directly. If your agents' identities are owned by a platform, migrating off that platform means destroying those identities and recreating them elsewhere. The switching cost is not the difficulty of moving prompts and configurations. It is the loss of the accumulated context that makes the agents useful.

How Buzz solves it

Buzz is built on Nostr, a protocol designed for decentralized social networking. The relevant property of Nostr for Buzz's purposes is that every participant — human or agent — holds a cryptographic keypair. The keypair is not issued by Buzz. It is not issued by any platform. It is generated by the participant and can be used across any Nostr-compatible system.

What this means in practice: an agent configured in Buzz has an identity that is cryptographically its own. It authenticates by signing events with its private key. Its messages, its actions, its contributions — all are verifiable as having originated from that specific agent, regardless of which model is behind it, which harness is orchestrating it, or which relay is delivering its messages. If a team moves from Block's managed hosting to a self-hosted instance, the agent's identity moves with them. If a team switches the model powering the agent from Claude to Gemini, the identity persists. The identity is not a feature of the platform. It is a property of the agent.

This has practical implications that go beyond portability. An agent that commits code can sign the commit with its own key. An agent that reviews a pull request leaves a review that is cryptographically attributable. An agent that participates in an incident response leaves a record that can be audited. The trail does not break when the API key rotates, because the identity is not the API key.

Buzz's architecture separates agent identity from model access. The identity is a keypair. The model is a configuration choice. They are independent axes. Most agent platforms today conflate them.

What's genuine and what's marketing

Every product announcement makes claims. It is worth distinguishing which parts of Buzz's proposition are structurally unique and which are well-executed versions of ideas that are becoming standard.

Structurally unique: the identity layer. No other major agent platform gives agents portable, cryptographic identities that are independent of the platform. This is not a feature Buzz added to an existing architecture. It is a consequence of building on Nostr, which was designed to solve exactly this problem for a different domain. The decision to use a decentralized protocol for agent identity is novel, and it has downstream consequences — for auditability, for reputation, for portability — that are not achievable within a platform-owned identity model. Whether Nostr is the right protocol for this use case is a separate question, but the architectural choice is genuinely different from what exists.

Well-executed but not unique: the collaboration model. Shared channels, threads, direct messages, voice, code repositories — this is a well-designed workspace, but the category is crowded. What distinguishes Buzz's execution is that agents are first-class participants rather than integrations bolted onto a human platform, but that distinction will erode as every collaboration tool adds agent support. The structural advantage is the identity layer. The UX is good but replicable.

Strategically significant: open source from a major company. Block is not a startup. It is a public company with a market cap in the tens of billions, the parent of Square and Cash App. When a company of that scale releases an agent platform under Apache 2.0 with a self-hosting option, it changes the economics for every startup building proprietary agent collaboration tools. Free and open source from a credible maintainer resets the floor for what teams will pay for. The fact that Block built this on an open protocol rather than a proprietary stack makes the bet even clearer: they are betting that the infrastructure layer for agent collaboration should be a public good, not a proprietary platform. Whether that bet pays off depends on adoption, but the direction of the bet is legible.

Buzz and GitButler: two layers of the same problem

Buzz was not the only significant agent infrastructure release this year. GitButler, the Git client founded by Scott Chacon (GitHub co-founder, author of Pro Git), has been quietly building infrastructure for the same problem from a different layer of the stack.

Where Buzz addresses the collaboration layer — who is working on what, how do agents communicate, how is identity established — GitButler addresses the version control layer: how do you manage code when multiple humans and multiple agents are changing it simultaneously?

The core innovation is virtual branches. In traditional Git, you work on one branch at a time. Switching branches means checking out a different set of files — context-switching your working directory. Git worktrees mitigate this by giving each branch its own directory, at the cost of disk space and coordination overhead. GitButler replaces both models. Multiple branches are applied simultaneously within a single working directory. Files from different branches coexist in the same workspace. There is no checkout. There is no context switch.

This matters for agents because agents produce code in parallel. An agent fixing a bug, an agent implementing a feature, and an agent refactoring a module can all operate on the same repository at the same time, each on its own virtual branch, without conflicting at the filesystem level until their changes actually overlap. GitButler detects conflicts immediately — not at merge time — because all branches share a single working tree.

The integration with agents is deeper than the branching model. Each virtual branch can be bound to an independent agent session. GitButler provides hooks for Claude Code and Cursor that automatically route file edits to the correct virtual branch and handle commits when a session ends. A single command — but rub — handles assign, move, squash, and amend operations, which is how you post-hoc organize files into branches when multiple agents have been working across multiple concerns.

GitButler's documentation describes seven multi-agent collaboration patterns: parallel feature development, sequential handoff between agents, cross-agent commit transfer, agent code review cycles, agent swarms on a shared branch, exploratory development (multiple approaches in parallel, keep the winner), and emergency hotfix without disturbing ongoing work. These are not theoretical. They are documented patterns that the tool's primitives make possible.

The comparison that matters. Buzz and GitButler are not competitors. They are complementary infrastructure at different layers. Buzz gives an agent a portable identity and a place to communicate with humans and other agents. GitButler gives that agent a way to produce and manage code alongside other agents without stepping on each other's work. Together they sketch what agentic software engineering infrastructure looks like: identity at the protocol layer, virtualized branching at the version control layer, agents as first-class participants at both. The verification layer — determining whether any of this agent-produced code is actually correct — remains the hardest piece of the stack, and the subject of a separate discussion.

Buzz and GitButler are not the final form of agent infrastructure. They are early, credible bets on what the stack needs to look like. Buzz bets that the collaboration layer — identity, communication, shared context — should be open at the protocol level, with agents holding their own cryptographic identities rather than leasing them from a platform. GitButler bets that the version control layer needs to be rethought from first principles for a world where multiple agents produce code in parallel, and that virtualized branching is the right abstraction. Neither bet is proven. Both are made by people with the track record to be taken seriously — Block on one side, Scott Chacon on the other.

What neither addresses is verification. An agent with a portable identity can produce coherent-looking code on a virtual branch. The identity tells you who. The branch tells you how the work was managed. Neither tells you whether the change is correct within the context of the whole system. That is the verification layer, and it remains the hardest piece of the stack.

The test for agent infrastructure is not whether agents can participate. It's whether you can answer "who did what, why, and was it correct?" six months after the fact, after rotating credentials, switching models, and changing platforms. Buzz and GitButler get you closer to an answer than anything else currently available. But the "was it correct?" column is still empty.

References: