Block, the company Jack Dorsey runs alongside Square and Cash App, shipped a new team chat platform called Buzz on July 21, 2026. It is free, open source, and built so AI agents sit inside your channels as full members instead of bolt-on bots. We spent the week pulling it apart, and the pattern underneath it is the real story: agent-native team chat, where the chat app, the git layer, and the model or agent framework are three separate pieces that snap together. That separation is the part every operator running a 10 to 50 person company should copy, whether or not you ever install Buzz itself.
What actually shipped
Buzz is a group chat app where employees and AI agents share the same channels, the same threads, and the same identity system. It is built on the Nostr protocol, which means every human and every agent gets its own cryptographic identity rather than a vendor-issued login, and the code is public on GitHub under an Apache 2.0 license. You can read the full pitch on the official Buzz site. None of that is the interesting part for an operator. The interesting part is what sits under each agent.
Every agent in Buzz is model-agnostic. You can point one agent at Claude Code, another at Codex, another at Goose, or at a custom framework you built yourself, and swap the harness underneath any of them without losing the conversation history or the working context. Agents also get their own git workflow: they open feature branches, work in parallel git worktrees so three agents can build three versions of the same page without colliding on the same files, and push to hosted repositories. There is even an audio huddle mode where you talk to an agent live instead of typing back and forth.
Why the harness layer is the real story
Most teams that added AI to their chat app bolted a single bot onto a single model. Ask it a question, get an answer, done. That pattern breaks the moment a better or cheaper model ships, because the workflow, the prompt, and the integration are all welded to one vendor. Buzz proves the fix is architectural, not a feature: keep the workflow layer and the model layer separate so you can swap one without touching the other. That is the same principle behind Anthropic's Model Context Protocol, the open standard that lets an agent call the same tools no matter which model is driving it. Once your tools and workflows talk to agents through a standard interface instead of a vendor-specific plugin, the model becomes a swappable part, not a foundation you pour concrete on.
This matters more than the chat app wrapper. Operators do not need a Slack replacement this quarter. They need to stop building automations that only work with one model's quirks. When the next model drops and it is cheaper or faster, you want to change one config line, not rebuild three integrations.
Parallel worktrees: agents that do not step on each other
The git-native piece is worth sitting with. Git worktrees let you check out multiple branches of the same repository into separate folders at the same time, so you can run parallel experiments without one overwriting the other. Buzz builds this in by default: ask an agent for three landing page directions and it can spin up three worktrees, build all three in parallel, and hand you branches to compare instead of one committee-designed compromise.
For an operator, the lesson translates directly. Whatever your AI agents touch, whether that is drafting ad copy, restructuring a pricing page, or rewriting a client proposal, you want the option to generate a few real variants in parallel. A single answer you either accept or argue with is the old pattern. That is a workflow decision, not a chat app decision, and you can build it into your own systems regardless of which chat tool your team uses.
Old pattern vs the agent-native pattern
| Old pattern | Agent-native pattern |
|---|---|
| One bot bolted onto one model in Slack | Agents as channel members, model swappable per agent |
| Automations break when a model gets deprecated | Workflow and model layers are separate, swap without rebuilding |
| One draft, one shot, accept or redo | Parallel worktrees produce a few real variants to compare |
| Agent work lives in a separate tool from team chat | Agent work and human conversation share the same thread |
What to build this quarter
Three moves, in order of how fast you can do them.
- Audit your current automations for model lock-in. If a Zapier flow, a chatbot, or an internal tool only works because of one model's specific prompt formatting, that is fragile. Rebuild the interface so the tool call is standard and the model is a variable.
- Stop treating agents as a separate tab. If your team opens a different app to talk to an agent than the one they use to talk to each other, you are paying a context tax every time. Agents that live where the conversation already happens get used more, because nobody has to remember to go ask them something.
- Build for parallel output, not single output. Wherever your team currently gets one draft, one landing page, one campaign angle from an agent, ask for three instead and pick the best. It costs almost nothing extra when the agent is already running.
None of this requires switching chat tools. It requires building your AI operations layer so it does not care which model or which chat app sits on top of it. That is exactly what we mean when we talk about an AI Operations Agent. It is a system that plugs into the tools your team already uses, keeps working when the underlying model changes, and does not lock you into one vendor's roadmap.
What we are building at luup
We run a 40-person real estate group ourselves, so we build our own AI systems the same way before we ever hand them to a client. Every agent we deploy, whether it is answering leads, drafting follow-ups, or managing a pipeline, is built so the model underneath can change without the workflow breaking. That is not a theoretical stance. It is the only way a system stays useful when a new model beats the old one on price or speed every few months, which has been the pace of this market all year.
Two facts we hold ourselves to when we build these systems: agents work around the clock, not on a shift, and clients own 100 percent of the code and files we build for them. Nobody gets locked into our stack, the same way Buzz is trying to make sure nobody gets locked into Slack's. We also see the same admin drag in almost every client we onboard. Most operators are losing 10 or more hours a week to manual follow-up, scheduling, and status updates that an agent sitting inside the existing chat and calendar tools can absorb without anyone changing how they work.
If you want to see this pattern applied to a real business rather than read about it in the abstract, our case studies walk through builds we have shipped for operators in this exact size range. If you are earlier in the process and want a system mapped to your actual workflow, the AI Concierge assessment is a 999 euro engagement that gets credited straight to the build. Most first systems go live in days to weeks, not quarters.
The bottom line
Buzz is not the product every operator needs to adopt this week. The pattern it makes visible is what matters: chat, code, and model are separating into independent layers, and the businesses that build on top of that separation will not have to rebuild every time the model landscape shifts again. We track this kind of signal every week on the luup blog. If you want a quick read on where your own operation is leaking time before you decide what to automate first, run it through our revenue leak heatmap. The chat app you use in six months is not the decision that matters. The decision that matters is whether your workflows are built to survive it changing.
We also keep an eye on how this connects to automation builds we run for clients, because the same swappable-model principle applies whether the front end is a chat channel, a voice line, or a form on your website. The tools will keep moving. The operators who win are the ones who stopped betting their systems on any single one of them.