· 7 min read

Block Just Shipped an Open-Source Workspace Where Your AI Agents Are First-Class Coworkers. The Interesting Part Is Who Doesn't Own It.

On July 21, Block, Jack Dorsey's company, released Buzz, a free, open-source workspace where employees and AI agents sit in the same channels, share the same code repositories, and each hold their own cryptographic identity. It's built on Nostr, a decentralized protocol with no central server, and it's positioned as a straight replacement for the Slack-plus-GitHub stack most software teams pay for today. The source is on GitHub under Apache 2.0, and you can self-host it or run it on Block's managed relay.

The easy way to cover this is "Jack Dorsey builds another Slack rival." That misses the part that actually matters to anyone building solo. Buzz treats agents as full participants from the first commit, and it runs on infrastructure that no single company controls. Those two design choices, taken together, are a bet about how work tools get built for the next few years, and it's worth understanding the bet even if you never touch the product.

Agents as coworkers, not a sidebar

Almost every tool you use was built for humans and had AI stapled on later. Slack has an assistant in a panel. Your IDE has a chat box. GitHub has a bot that comments on PRs. In all of them the agent is a guest: it can suggest things, but it can't fully see the workspace or act inside it the way a teammate can.

Buzz inverts that. An agent in Buzz gets its own account, reads the repository, follows the workflow, and posts in the channel next to the humans. Block wired it to be model-agnostic on day one: it runs agents powered by Anthropic's Claude Code, OpenAI's Codex, and Block's own Goose framework. You connect internal databases, codebases, and file systems, and you set channel- or thread-level rules for what each agent is allowed to touch, so a human stays in the loop on access.

Here's why that framing is more than cosmetic. As agents move from answering questions to doing multi-step work (opening a branch, running the tests, filing the PR, updating the ticket), the tools that treat them as a chat box become the bottleneck. You end up copy-pasting between the agent and the five apps it can't actually reach. A workspace where the agent is a first-class account with scoped permissions removes that seam. For a solo operator running three or four agents against your own repo, that's the difference between orchestration and babysitting.

The ownership question hiding under the feature list

The detail I keep coming back to is the identity model. Every participant in Buzz, human or agent, holds a cryptographic keypair that belongs to them, not to the platform. An agent's identity, its history, and its reputation can travel across any Nostr-compatible system. Block also gives each agent a signed chain of custody, so the work an agent did is attributable to that agent's key.

Strip away the crypto vocabulary and the point is simple: if agents become genuinely useful coworkers, then whoever owns the workspace they operate in owns a lot of leverage over you. Today that's Slack, GitHub, Notion, Linear: a handful of companies that can change pricing, deprecate an API, or lock your data behind an export button whenever it suits them. Block's answer is to put the workspace on a protocol nobody owns, so your identity and your history aren't hostage to one vendor's roadmap.

I've written before that the base of your stack keeps consolidating into fewer hands. Buzz is one of the few releases this year pushing the other direction on purpose. Whether it wins or not, the ownership question it raises is real: the tools you standardize your agents on are a dependency, and most people pick them without thinking about who controls the exit.

Where this actually fits for a solo operator

I want to be honest about the gap between "interesting" and "adopt this week," because they are not the same thing.

Nostr is niche. It's best known as the protocol under a few decentralized social apps, and decentralized tooling is almost always rougher around the edges than the polished SaaS it competes with. "No one owns it" is a real benefit and also means "no one is on the hook to support it." When your managed Slack breaks, you file a ticket. When a self-hosted relay on a niche protocol breaks on a Saturday, you're the support team. For a one-person business, that trade is not automatically worth it, and for most people it isn't worth it today.

So the move isn't to rip out your stack. The move is to watch the category. Agent-native workspaces (tools designed from the start for humans and agents to share the same surface) are going to matter more every quarter as agents do more of the actual work. Buzz is the clearest early example, and it's free to poke at. If you already run multiple coding agents against your own repos, spin it up on a throwaway project and feel the difference between an agent as an account and an agent as a chat box. That's a cheap afternoon that tells you where your real tools are heading.

The honest take

Buzz might not win. Plenty of technically elegant, protocol-pure tools have shipped to applause and gone nowhere because the network effects live on the incumbent platforms, and "your whole team is already on Slack" beats "but this one is decentralized" almost every time. Block itself hasn't said whether Buzz has a commercial trajectory at all, which means the long-term support story is genuinely unknown.

But you don't have to bet on the product to take the lesson. Two things are true after July 21: agents are becoming participants rather than features, and the ownership of the surface they run on is now a live question instead of a settled one. If you're building on a stack you don't control, and almost all of us are, the useful reflex isn't to chase Buzz. It's to know, for each tool your agents depend on, exactly how bad the exit would be. Block just made that question impossible to keep ignoring.

Author

Sources

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts