Jack Dorsey’s Buzz takes a direct shot at Slack, with AI agents baked into the chat

Jack Dorsey has a new workplace app called Buzz, and it’s aiming squarely at the overlap between Slack, GitHub, and the internal AI tools teams keep stitching together.

The pitch is simple enough. Buzz is a group chat platform for teams, but it treats AI agents as first-class participants instead of add-ons. Dorsey describes it as “model-agnostic, decentralized, self-sovereign, and open source.” That’s a lot of ideology for a chat app, but the product idea is clear. It’s a Slack-like workspace where humans and agents can work in the same threads, with GitHub-style project work living alongside team conversation.

That’s a sensible read on where a lot of teams are headed. It’s also early. Buzz is available as a free desktop app for macOS, Windows, and Linux, and the code is on GitHub. The company says the product is still in its early stages, which matters. This isn’t something you replace Slack with next week.

The product idea is obvious. The timing is not.

The last two years have pushed teams into awkward tooling sprawl. Chat lives in Slack or Teams. Code reviews and issues live in GitHub. Agent workflows live in whatever internal wrapper a startup hacked together last quarter. If you’re using AI agents for support, triage, content generation, deployment checks, or data work, they usually sit one layer below the actual conversation. Humans ask in one place. The work happens in another. Context gets lost on the way.

Buzz is trying to collapse that split.

That’s the appeal. If an agent can join a channel, inspect a repo, summarize a pull request, file a task, or answer a question in the same thread where the request was made, you cut down on context switching and the usual copy-paste mess. For teams already building around agents, that’s not a gimmick. It’s useful.

Slack has moved in this direction too, mostly through integrations and layers on top. Buzz sounds more opinionated. It wants agents inside the core product model, not sitting off to the side behind app integrations and bot commands.

Open source changes the equation

The open source part matters more than the branding. If Buzz’s code is public, teams can inspect how it works, extend it, and self-host it if they want tighter control. That matters for companies that don’t want chat content, repo metadata, or agent prompts flowing through a third-party SaaS layer they can’t fully audit.

Self-hosting isn’t free, though. It brings the usual tax: deployment, upgrades, auth, data retention, observability, incident response, and the reality that “we’ll just run it ourselves” usually means someone on the infra team owns it forever. For startups, that may be fine. For larger companies, it turns into a platform decision fast.

Open source also gives developers a way to adapt the product around team-specific workflows. If your agents need a narrow set of actions, or your org wants a different permission model, you can patch the app instead of waiting on a vendor roadmap. The catch is plain enough: custom software only helps if your team can keep it maintained.

“Model-agnostic” is the right idea

Dorsey’s claim that Buzz is model-agnostic is worth taking seriously. In practice, it means the platform shouldn’t force teams into one LLM provider or one agent stack. That’s a sensible choice in 2026. Model selection is getting more fragmented, not less. Teams want a fast model for lightweight routing, a stronger one for reasoning, maybe a local model for sensitive data, and a specialized workflow agent somewhere in the middle.

If Buzz really supports interchangeable models cleanly, that’s a better fit for enterprise reality than a chat app tied to one vendor’s AI endpoint. It also avoids a common failure mode in agent products: they age badly when the underlying model API changes price, latency, or behavior.

The trade-off is complexity. Model-agnostic systems are harder to optimize. You can’t assume one prompt format, one function-calling dialect, or one latency envelope. Good abstractions help, but they also hide details that matter when an agent is doing real work. If Buzz wants to be more than a demo, it’ll need strong controls around tool execution, permissions, and audit logs. Otherwise “AI agents in chat” becomes “AI agents occasionally doing something useful and sometimes doing something stupid in public.”

Slack is the obvious comparison. GitHub may be the bigger one.

Buzz is being framed as a Slack challenger, and that makes sense at first glance. The interface looks like chat. The usage pattern starts with conversation. But the more interesting competition may be with the mashup of Slack plus GitHub plus internal agent tools that many engineering teams have already built by accident.

That stack is messy. It works, but it’s fragmented. A thread in Slack links to a GitHub issue. A bot posts build status. Another agent watches for incidents. A third one drafts release notes. Everyone depends on everyone else’s app tokens and webhooks. It’s brittle.

A product that unifies chat and project work in one place has a real shot because the pain is real. The question is whether Buzz can handle the operational detail that makes those workflows safe:

• fine-grained permissions for channels, repos, and agents
• auditability for every agent action
• clear human approval steps for destructive operations
• good event handling when multiple agents respond at once
• sane rate limiting and queueing so bots don’t turn chat into a firehose

Without that, the platform turns into a toy with a decent pitch.

The real problem is trust

A lot of the current AI collaboration pitch assumes the hard part is getting the agent to do the task. It isn’t. The hard part is making the task trustworthy enough that a team can let the agent operate inside shared systems.

Chat makes that harder, not easier. Chat is high-bandwidth and informal. It works well for quick decisions and badly for hidden side effects. If an agent can edit a repo, summarize a customer thread, or kick off a deployment from inside a channel, the product has to make the boundaries obvious. Who approved what? What changed? What can be rolled back?

That’s where decentralized and self-sovereign ideas could matter if Buzz actually implements them in a meaningful way. In a workplace app, the useful version of that language is simple. Teams should be able to control identity, hosting, access, and data boundaries without handing everything to a vendor.

But the words can also be a distraction. Decentralized doesn’t help if the UX is clunky. Self-sovereign doesn’t matter if the action trail is a mess. Open source doesn’t solve governance by itself.

Why startups should care anyway

For a newer company, Buzz could be interesting precisely because it doesn’t have Slack gravity to fight yet. If your team is already building with agents, starting from a workspace that treats them as native participants could save a lot of glue code. You may not need to bolt a chatbot onto a chat app, then bolt another automation layer onto GitHub, then build a separate dashboard for agent activity.

The migration risk is still real. New infrastructure always looks cleaner than it is. Moving a team into a fresh collaboration system means retraining habits, rebuilding integrations, and trusting a product that says up front it’s early. That’s a lot to ask when Slack already exists and your team’s muscle memory lives there.

So the sane read is this: Buzz is worth watching as an architecture bet, not as an immediate workplace replacement. If it matures, it could become a cleaner home for teams that want chat, code, and agents in one place. If it stalls, it’ll join the long list of products that were right about the trend and too early on the execution.

For now, the useful detail is simple. The next fight in workplace software may not be over messages at all. It may be over which system gets to own the agents that do the work.