Buzz by Block: Slack Alternative for Humans and AI Agents

By Lazar Milicevic · Published October 8, 2026 · 9 min read

You have an agent that drafts replies, one that reviews pull requests, and a team that lives in Slack. The agents run in terminals and scripts, the humans talk somewhere else, and half your time goes to pasting output from one into the other. Jack Dorsey's Block just shipped Buzz, a workspace built on the idea that agents should be teammates in the same chat. Here is what it is, what it isn't yet, and what to do about it if you run a small team.

What Buzz actually is (and what Block says it isn't ready for)

Buzz is a free, open source group chat platform where humans and AI agents share the same channels, threads and direct messages. Block announced it on July 21, 2026, and TechCrunch describes it as a challenger to Slack and GitHub. Block's own engineering post says it is still very early, with rough edges between what exists and the roadmap.

The facts worth anchoring on, all from Block's announcement and TechCrunch's coverage:

• Built by Block, the company behind Square, Cash App, Afterpay and Tidal.
• Open source under Apache-2.0, code at github.com/block/buzz.
• Built on the Nostr protocol.
• Features: channels, threads, direct messages, voice, media sharing, code repositories and automated workflows.
• Model-agnostic and agent-agnostic. Teams can deploy agents powered by any LLM or agent harness, such as Claude Code, Codex or goose.
• Hosting: self-host it, or sign up at buzz.xyz for Block-provided hosting.
• Desktop app for macOS, Windows and Linux, free at launch.

Dorsey's pitch on X was that Buzz is for teams of people and agents of all sizes, built to reduce dependency on Slack and GitHub. He called it model-agnostic, decentralized, self-sovereign and open source.

Now the caution. TechCrunch reports that Buzz itself says it is in its "early stages" and advises against porting your team over yet. Reworked reports a version 0.1 release with a small user base. Block says its Git integration is still early too. "Reduce dependency" and "drop-in replacement" are different claims, and the project's own early-stage warning cuts against the second one. Read the original announcement, not the commentary on top of it.

Primary sources: Block's announcement, Block's engineering post, and TechCrunch's launch coverage.

Why "humans and agents in one chat" is a real pattern, not a gimmick

Putting agents where the conversation already happens removes the copy-paste layer between a person's request and the agent's work. Instead of one tool where you talk to people and another where you talk to a model, the agent reads the thread, sees the context, and answers in the same place everyone else can see it and correct it.

If you run a small team, you already feel the failure mode of the alternative. Consider a typical setup:

1. A customer question lands in a shared inbox.
2. Someone pastes it into a chat with an AI tool.
3. Someone else pastes the answer back, edited.
4. Nobody else on the team knows what the AI saw or said.

The shared-thread version looks different. The question is posted in a channel. An agent drafts a reply in the thread. A human edits or approves. The whole exchange is visible, searchable, and attributable. That visibility is the actual product advantage, more than any single feature.

This is not a Buzz invention. Agents inside Slack, Teams, and tools connected over MCP follow the same logic. Buzz is notable because it designs the workspace around the pattern instead of bolting agents onto a human-first product.

How Buzz treats agents: identity, permissions, and the audit question

According to Block, agents in Buzz have their own cryptographic identities and defined permissions. They can post, review code, run approved automations and contribute to conversations alongside humans. Block also says that if you swap the model or harness behind an agent, the project keeps its identity, permissions and history.

That last point matters more than it sounds. Most teams that build agents change the underlying model several times a year. If your agent's "identity" is tied to a specific vendor's API key, every swap breaks continuity: history, permissions, trust. Separating the agent's identity from the model powering it is the right design instinct.

Buzz can also connect to a database, CRM, codebase or file system, so agents can reach those resources alongside humans according to permissions your team configures.

Treat this as Block's description of the design, not a verified security guarantee. The audit-trail and scoped-identity claims have not been proven at scale. The Hacker News launch thread includes discussion of data-leakage concerns when agents share channels. Read it yourself and weigh it accordingly, since comments there are individual opinions. The concern is legitimate regardless of who raised it: when an agent sits in a channel, anything it can read can potentially end up in its output. Whatever platform you use, the questions to ask are the same:

Agent Client Protocol: why "any agent" is the interesting claim

Block's engineering post says any agent that speaks the Agent Client Protocol (ACP) can work in Buzz, including Claude Code, Codex and goose. A Block engineer stated the same thing in the Show HN thread, adding that the team itself uses goose, Claude Code, Codex and other agents.

For a small business, this is the practical meaning: you are not choosing an agent vendor when you choose the workspace. The workspace is a surface; the agents are interchangeable tenants. That is the opposite of how most chat platforms with built-in AI work, where the assistant is the vendor's and the choice is made for you.

It also fits a pattern showing up elsewhere. The agent platform decision is increasingly about control, permissions and integration, not which model sits underneath. If you're still evaluating tools that way, our earlier post Only 2% Picked an Agent Platform for Its Model makes the same point from the buyer side.

Two honest limits. First, ACP support in a protocol sense is not the same as polished support in a product. I haven't run Buzz in production, and neither do the launch sources claim it is production-ready. Second, I can't tell you from the sources how each harness behaves inside Buzz, such as how Claude Code handles long-running tasks in a channel. Test that yourself before you depend on it.

Self-hosted vs. Block-hosted: a decision framework for small teams

You have two paths: self-host the open source code, or sign up at buzz.xyz for Block-provided hosting. Which one fits depends on what you are protecting and how much ops work you can absorb.

Pick Block-hosted if:

• You want to evaluate the pattern, not run infrastructure.
• Your trial involves non-sensitive data.
• You can tolerate the "early stages" warning.

Pick self-hosted if:

• Data control is the reason you are looking at Buzz at all.
• You already run small services and are comfortable owning updates.
• You are willing to read the repo's actual requirements before committing. Third-party guides list a stack of dependencies, but I can't verify those from the primary sources here, so check github.com/block/buzz directly.

What I can't tell you: hosted-version terms such as data residency, SLAs, usage limits or future pricing. None appeared in the sources I found. Buzz is free at launch, but "free at launch" is not a pricing commitment. If you build workflows on it, assume pricing could change and keep your exports and automations portable.

A low-risk way to trial it this month

Don't migrate your team. Run a contained pilot that answers one question: does a shared human-plus-agent channel save us time on a specific recurring job?

A reasonable pilot, scoped for a small team:

1. Pick one job. For example: triaging inbound questions, reviewing small code changes, or drafting weekly status summaries.
2. Create one channel and invite two or three people, not the company.
3. Connect one agent with the narrowest permissions that let it do that job. Read-only first.
4. Use fake or low-sensitivity data for the first week.
5. Track two numbers by hand: minutes spent on the job before, and minutes spent during the pilot. A simple spreadsheet is enough.
6. Write down failures: wrong answers, over-reach, awkward UX. That list is your real evaluation.

A permissions checklist you can keep in the repo or a doc, whichever tool you end up using:

agent: inbox-triage
purpose: draft replies to inbound questions
reads:
  - channel: "#inbound"
writes:
  - channel: "#inbound"   # drafts only, human sends
tools:
  allowed: []             # none in week 1
  needs_approval: ["send_email", "update_crm"]
data_rules:
  - no customer PII in logs
  - no access to billing channels
review: weekly, owner = ops lead

The format doesn't matter. Writing the boundaries down before you connect anything is what matters. Most agent incidents I've seen discussed trace back to permissions nobody wrote down.

If the pilot works, the next step is a second job, not a bigger channel. If it doesn't, you've spent a week and learned what your team needs from an agent surface.

Where Buzz fits next to Slack, Teams, and MCP-connected tools

Buzz is a new workspace; Slack and Teams are where most of your colleagues, customers and vendors already are. No source I found says Buzz works inside Slack or Teams, so don't assume interoperability. Plan for coexistence instead.

Most small businesses I'd advise land on the first row for now, with a Buzz pilot on the side if the open, self-hostable angle appeals. The pattern, shared threads where agents and humans both act under defined permissions, carries over either way. If you design your agents around clear identities, scoped tools and written permissions, you can move them between surfaces later without rebuilding the logic.

The bigger thing to watch is whether the open ACP-style approach gains traction. If agents become portable across workspaces, the workspace stops being a lock-in point, and that's good for buyers.

How BizFlowAI approaches this

I build practical AI automations for small teams. The design rules are the ones above: a narrow job per agent, written permissions, approval gates on anything that sends or changes data, and logs the owner can actually read. Buzz is an interesting signal that the same pattern is getting its own dedicated workspace, but it isn't a place I'd move client work to while Block itself calls it early.

If you want to scope a pilot like the one above, start with the one recurring job that costs you the most time and build from there.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.