Buzz Jack Dorsey: human + AI agent workspace (buzz.xyz)

Buzz Jack Dorsey in one line

Buzz (buzz.xyz) is an open-source workspace announced on 21 July 2026 by Block, where humans and AI agents share the same channels, threads and permissions, instead of pasting agent output into Slack.

If you search “Buzz Jack Dorsey”, you mostly get launch notes. Here we cover who built it, the architecture reason, what we saw hands-on, and what an SME should freeze before production agents.

Who created Buzz?

Buzz is a Block (formerly Square) product, Jack Dorsey's company, also known for Cash App and open-source AI investment (including goose). The official post is on Block's blog: Introducing Buzz: where humans and agents work together.

Jack Dorsey fronts the launch in the press (TechCrunch and others frame it as a potential Slack / collab+agents rival). Not an anonymous side project: a strategic Block brick on agent infrastructure.

On product, Bradley Axen (Head of AI Capabilities at Block) states the bet: every company will need a place where humans and agents work together; the question is whether that place is proprietary or open. Block built Buzz for the open camp.

Announced license: Apache-2.0, code at github.com/block/buzz. Managed hosting via buzz.xyz or self-host. Open source is the core argument against lock-in from proprietary agent platforms.

Why Buzz was created

Block says it open-sourced AI tools for two years, then saw a pattern: productive work does not happen when someone “asks AI for help” in a corner. It happens when humans and agents are in the same room, on the same task, with shared context. No platform was designed for that, so they built one.

The second “why” is structural. Many companies build agent stacks inside proprietary platforms: access rules, allowed models, conversation formats set by the vendor. That fragments the org and creates dependency. Buzz wants an open standard for human/agent collab, like code you version yourself.

The third “why” is identity. Buzz is built on Nostr: every participant, human or agent, holds a crypto keypair that belongs to them, not a platform account. Agent identity is not a vendor API key. It is portable and verifiable. Without its own identity, an agent stays a plugin bolted onto SaaS.

In practice: stop endless copy-paste between agent terminals (Claude Code, Codex, goose…) and team chat (Slack), and reunite conversation + code + agents under a relay you can control.

What Buzz does (functionally)

The UI is familiar: channels, threads, DMs, voice, media, search. Plus still-early Git/repos, and automated workflows. Agents are not one-shot assistants in a sidebar: they have permissions, can post, review code, run approved automations, and stack with several humans on the same thread.

Buzz claims model-agnostic and agent-agnostic: Claude Code, Codex, goose, local model, or home-built harness. The workspace does not prescribe the engine. It prescribes the place and tool access rules (CRM, repo, files) the team configures.

Not magic: a collab surface. Quality still depends on harness, model, permissions, and your approval policy.

Our hands-on take (kengdev)

We opened a Buzz workspace and wired an agent into a Welcome-style channel. First reflex: a plain question to see if the agent behaves like a thread coworker, not a side chat. Ask: “give me examples of what you can do”.

The answer lands in the thread, structured (dev, research, content, design, automation), with starter prompts and a nudge to specify time saved. No magic panel off-stage: work shows where the team already reads. First “ah”: delegate by mention, like a human, with a thread anyone can reread later.

Going deeper, we get the same feel as other serious hands-ons of the product: Buzz is not “another chatbot inside Slack”. It is a familiar mix (team-chat channels / threads) + first-class agents (identity, history, delegation) + harness of choice (Claude Code, Codex, goose, local models). The agent can sit on a harness, pick a model, and in more advanced flows delegate and work in parallel (including git worktrees).

What we really like in use: tagging the agent and seeing it reply in-thread with status updates as it progresses (build, commit, deploy) feels natural. The thread becomes a brief for the rest of the team. We no longer rebuild a terminal transcript to explain “what the agent did”. Shared compute (a relay / a beefier machine offered to a community) and Nostr identity (portable keys, Lightning path for future compute micropayments) are also what separates Buzz from a plain agent manager bolted onto closed SaaS.

What still slows us, and it shows from the first sessions: we cannot see the agent terminal. There is an activity view, but if you are used to watching a Claude Code session scroll, Buzz UI stays abstracted. We also felt, without strict measurement, that round-trips are slower than a local harness session: for one-offs we instinctively fall back to the terminal. Another limit: we want more control over the backend session (reuse the same session id for the same agent, replay, inspect). Without that, full-time integration into a team flow stays hesitant.

Internal verdict after this hands-on: we like the model and can genuinely imagine working as a team this way. For mid-size tasks (scoping, explanations, small batches, shared status), it already fits. For large complex projects, it is not yet the single base. The long-term differentiator (shared compute + open identity + shared thread) is real; the product stays early. We keep Claude Code / Codex for deep coding, and use Buzz for multi-human multi-agent visible collab, with a written approval policy before we widen scope.

What FR briefs underplay (SME angle)

Many FR briefs stop at: “Jack Dorsey ships Buzz, open source, agents as members, Nostr”. True, and not enough to decide.

What is often missing: the approval contract (HITL), secrets and write mapping, terminal vs workspace split, and the difference between multi-agent chat and a packaged ops agent on a business process (quotes, support, CRM).

If you run an SME, ask three questions before FOMO: (1) Where does the relay run and who reads logs? (2) Which actions can the agent take without a human click? (3) What if Buzz or the harness dies mid-sprint? Without written answers, you do not have a migration. You have a social demo.

Guardrails before you drop agents in

One policy page is enough to start: auto actions (format, lint, summary), actions that need a click (push main, secrets, migration), forbidden actions (live prod, payment, bulk delete). Version it like code.

Map flows: API keys, wired tools, customer data, thread retention. Open source and self-host do not replace a GDPR read and real least-privilege.

Split usages: deep coding in a terminal harness; visible collab (review, status, handoff) in a Buzz-like workspace; recurring business ops with a write allowlist. At kengdev, machine suggests → human validates stays non-negotiable, whatever the UI.

Measure time saved and escalation rate, not agent message count. More commits do not mean more value.

Buzz vs Claude Code vs Hermes Ops

Claude Code / Codex: execution harness, strong on terminal and patches. Buzz: multi-human multi-agent collab surface, strong on shared context and open identity. Hermes Ops (kengdev pack): ops agent wired to messaging + business tools, critical writes behind human confirmation, process perimeter rather than general chat.

You do not have to pick one tool forever. You pick the perimeter. Buzz pushes the “shared room”. It does not replace a production runbook or approval policy.

If you want to scope a first agent on a real process (support, quotes, ops), with or without Buzz in the loop, we can do it in 20-40 minutes.