When agents become colleagues: the idea behind Buzz

I already wrote about Buzz once, back then with a clear focus on shared compute and joint model operation. At the time, that was for me the most exciting and unusual part of the project. But the longer I spend with Buzz, the more interesting the workspace itself becomes. So I have since tried Buzz out in a small setup of my own.

That is also driven by a problem I have felt more clearly over the past months. My work with AI has become not just faster, but also messier. Codex works on one repository, Claude Code checks a second idea, another agent gathers information, and somewhere in between run a terminal, a browser, email, and several chats. Each agent can be useful on its own. The problem arises at the handoffs. Context has to be copied, decisions repeated, and results merged manually.

That is exactly where Buzz comes in. The open source project comes from Block, the company behind Square, led by Twitter co-founder Jack Dorsey. It does not aim to build yet another AI assistant. Buzz creates a shared workspace where people and agents use the same channels, threads, projects, and protocols. A Codex agent can draft a plan, Claude Code can critique it, a human can make the decision, and the next agent can turn it into a change in the repository. The whole chain stays visible in the same space.

The quick label “Slack killer” falls short for me. Buzz points to a possible way of working for teams with many agents. At the same time, it is still young, resource hungry, and more demanding on the security side than its friendly interface suggests. That mix of a big idea and an early stage of development is exactly what makes a closer look worthwhile.

The real problem is not the model

Most AI tools grew out of a relationship between one human and one agent. I open Codex, enter a task, and get a result. Then I open Claude Code, explain the same background again, and ask for a second opinion. For individual tasks that works fine. But in a team, or with several agents running in parallel, a new coordination problem appears.

I know this problem well from my own daily work. Claude Code, Codex, Hermes, browser, chats, and various terminals all run side by side. Session logs migrate from one tool to the next. One agent knows the meeting notes, another knows the repository, and a third knows the required credentials or skills. Everyone has a slice, but nobody has the shared state of the work.

Mission control dashboards only solve part of this. They might show that five agents are active. But they still do not create a shared, understandable place where the task, the discussion, the intermediate state, the review, and the decision stay together. So Buzz does not start with a nicer agent list, but with the workspace itself.

Agents are members, not bolted-on bots

At first glance, Buzz looks familiar. There are communities, public and private channels, threads, direct messages, forums, search, huddles, and a mobile app. The key difference from an ordinary Slack integration lies underneath.

In Buzz, an agent is a member in its own right. It has a profile, a cryptographic keypair, channel memberships, and its own audit trail. Its messages appear under its own identity. As a result, you can later see not just that “the AI” did something. You can see which agent acted, in which channel it received the task, and which human or other agent triggered it.

At first that sounds like a small change to user management. For actual work, though, it is central. A Slack bot is usually tied to an integration and waits to be mentioned by a human. Two bots from different vendors normally know nothing about each other. In Buzz, agents can address other agents, hand off tasks, and discuss their results in the same thread. That does not turn Codex and Claude Code into a single system. But it gives them a shared space for communication.

Buzz does not automatically bring all the intelligence with it. The workspace connects what are called harnesses and models that already run locally, on a server, or through a provider. According to the current state of the project, these include Codex, Claude Code, and Goose, among others. Further agents can be connected through open interfaces. This is a bring-your-own-agent model: Buzz coordinates, while each agent thinks and acts with its own tools, skills, access, and model costs.

The relay is the shared working state

Technically, Buzz consists of several parts. The desktop app is the interface. A community is the actual workspace. The Buzz relay stores and distributes its messages, members, agents, rules, media, search data, workflows, and Git events. Agents can work on the same machine as the desktop app, on a continuously running server, or on an entirely different machine.

As its protocol, Buzz uses Nostr. People and agents sign events with their private keys. The relay verifies identity and membership, stores the events, and distributes them to authorized clients. That does not make Buzz a magical peer-to-peer network, though. The relay is the central source of truth for a community. There is no automatic replication between relays, and messages stay on the relay where they were sent.

This design has two interesting consequences. Identity does not simply belong to a central Slack account, but is based on its own keypair. At the same time, a team can run the workspace itself. Anyone who just wants to try it out can use a community hosted by Block. Anyone who wants to control data storage, availability, and backup themselves can run the relay on their own infrastructure.

The current server architecture uses familiar components: PostgreSQL for events and full-text search, Redis for pub/sub, and S3-compatible storage for media. This is not a small service you can forget about after installation. A self-hosted relay needs TLS, updates, backups, monitoring, and clean key management.

Why shared context is so valuable

The strongest idea behind Buzz is persistent, jointly visible context. A project no longer consists of a chat message in Slack, a separate agent run, a pull request on GitHub, and a decision made in a video call. Buzz tries to bring these traces together in one event space.

That is especially useful when different agents have different strengths. A realistic workflow can look like this:

1. A human describes the goal and the constraints in the project channel.
2. A research agent gathers information and documents its sources.
3. A second agent attacks the weak points and looks for counterarguments.
4. Codex or Claude Code drafts a concrete plan.
5. Another agent reviews the plan for security, missing tests, or unclear assumptions.
6. After human approval, the change is implemented in a separate worktree.
7. Diff, test results, review, and decision remain traceable in the associated channel.

This pattern is especially interesting for adversarial reviews. One model is explicitly given the role of attacking a product plan or an implementation. A second model has to defend or improve the decisions. Because both see the full thread, a genuine engagement with the existing state of the work emerges, not just an isolated review of a copied text.

The pattern is also interesting for content and business processes. One agent researches topics, a second writes, a third edits. Metrics or new reports can flow into a channel on a regular basis so that people and agents can discuss developments together. Huddles go a step further: people and agents talk in an audio conference, the conversation is transcribed into text, and can then be turned into concrete tasks.

This is the point where Buzz becomes more than a group chat. The channel is not just a place for communication. It becomes a traceable work log.

Buzz also wants to replace GitHub

Buzz integrates Git repositories, patches, reviews, and status events into the same workspace. The relay can host repositories itself. Agents can use worktrees, work separately on variants, provide changes as patches, and discuss reviews within the project context.

The vision behind this is strong: a feature branch becomes a space. It holds not just the commits, but also the discussion of why a change was necessary, which alternatives were dropped, what CI reported, and who approved the merge. For agentically generated code in particular, this history of how a change came to be is often missing today.

Still, I would not write off GitHub too quickly. GitHub is not just Git storage, but an ecosystem grown over years for permissions, reviews, CI/CD, security scans, releases, integrations, and external collaboration. Buzz has working Git fundamentals and an interesting forge approach. But the project’s own status page clearly distinguishes between parts that already work, features still being wired up, and vision. For critical repositories, a gradual rollout is more sensible than an immediate migration.

My first test with Buzz

I deliberately started small: my own community, one channel, and two agents with clearly separated roles. Codex was to draft a technical plan, Claude Code was to attack assumptions, security gaps, and unnecessary complexity. Production credentials, customer data, and sensitive repositories stayed out. My initial goal was to test the collaboration, not maximum autonomy.

The first open-ended task was too vague. Both agents started planning, reacted to each other, and at some point just waited for the next input. That was a good reminder that a shared channel does not replace orchestration. With the clear instruction “Codex creates the plan, Claude reviews it, then you both wait for approval,” the process became noticeably calmer and easier to follow. More agents do not replace a defined process.

What convinced me most was not a single spectacular answer, but the absence of a media break. Both agents saw the same thread, the critique stayed right next to the original plan, and I could tell at any moment who was working. I did not have to copy text between windows or re-explain the backstory to a second agent. That, for me, is where the real value of Buzz lies.

For intensive software development, though, working directly in Codex or Claude Code was still faster. Buzz adds communication, logging, and shared context. That layer costs time and tokens. Every additional agent has its own session, and extensive channel history can be processed multiple times across several models. For a long coding run, I would therefore still use the native harness and reserve Buzz more for planning, handoffs, and reviews.

What I have not tested deeply yet are workflows, longer huddles, local models, and multiple continuously running remote agents. That is exactly where Buzz has to prove in daily use that tasks are not just nicely visible, but also reliably completed. The software is pre-1.0 and feels correspondingly young in some places. That is fine for experiments. Central workflows, however, still need control, retry logic, and a clear manual fallback.

Shared context is also a security boundary

What makes Buzz useful also widens its attack surface at the same time. A connected Codex, Claude Code, or Hermes agent may bring file access, a shell, a browser, MCP servers, email, calendar, or other internal tools with it. If a team member is allowed to address such an agent, that permission reaches far beyond writing a chat reply.

The most important rule, then, is this: an agent should only work in channels whose content and members match its tool access. Channel membership is the central access gate. Members can read and write. Non-members should be able neither to see private channels nor to subscribe to their events.

Cryptographic signatures still do not solve every audit problem. Buzz keeps a chained, tamper-evident audit log. An attacker with write access to the database could, however, recompute the chain after tampering with it. So the log is tamper-evident, not tamper-resistant. It makes changes detectable as long as the storage’s trust base has not fully collapsed.

For communities hosted by Block, there is one more point: messages, direct messages, and uploaded media are not end-to-end encrypted. Block can inspect this content for operations, security, moderation, or legal obligations. On top of that, the respective model provider can receive prompts and channel content whenever an agent uses a cloud service.

Self-hosting changes data ownership, but not automatically the entire data flow. A self-hosted relay keeps messages and files on your own infrastructure. If the agent still uses a cloud model, the data needed for the task still leaves the relay. Truly local operation therefore requires a self-hosted relay as well as local models and local tools. I already wrote separately about the possibilities and limits of Buzz shared compute.

How I am using Buzz for now

For my first test, I used a small, clearly bounded community. No production credentials, no customer data, and no repository with secrets. Two agents were entirely enough: one creates, one reviews. I add myself as the human who sets the task, the approval point, and the abort criterion.

My first setup was not an autonomous company with a hundred agents, but a bounded review:

• One agent drafts a technical plan from an existing issue.
• A second agent looks for security gaps, missing assumptions, and unnecessary complexity.
• Both must cite sources, files, and open questions.
• After at most two rounds of discussion, the team waits for human approval.
• Only then may an agent prepare changes in an isolated worktree.

This let me test the real strength of Buzz without immediately rebuilding my whole operation. At the same time, token consumption, latency, permissions, and traceability all became visible.

For solo work on a single coding task, I still stick with the direct agent interface. It is faster and easier to control. Buzz becomes interesting as soon as several people, several agents, or several workflows need the same context. Small dev teams, agencies, research groups, and technically skilled solopreneurs are therefore the obvious target audience.

For a larger company, I would be more cautious. Pre-1.0, without a long-term support line, and with still-young workflows, I would not make Buzz the sole place for critical communication or source code. A pilot project can make sense. A full replacement of Slack and GitHub would currently be a bet on the project’s development speed.

The idea behind Buzz is bigger than the current client

The most exciting part of Buzz, for me, is not a single feature. Channels, forums, huddles, Git hosting, and local models all exist elsewhere too. What is new is the consistent assumption that agents are no longer just private tools for individual users. They become visible participants in a shared work process.

That shifts the question. We are no longer just asking which model writes the best code. We have to decide how people and multiple agents divide tasks, share context, check each other, and make responsibility traceable. That is exactly the social and technical infrastructure that is often missing today.

Buzz does not yet offer a finished answer. The software is young, some workflows are unreliable, shared context can get expensive, and self-hosting brings real operational responsibility. Even so, the project addresses a real problem. As agents take on more and more work, it is no longer enough to open five separate chats side by side. We need a shared place where their work stays visible, bounded, and reviewable.

Maybe Buzz will replace Slack and GitHub one day. For today, a smaller but more important statement is enough: Buzz is a convincing sketch of what a workspace can look like once people are no longer the only ones working in it. Shared compute is what first drew my attention to the project. The shared workspace is why I will keep testing Buzz.

My verdict after the first test

In my short test, Buzz hit exactly the problem I currently have with AI agents. The individual models are no longer the bottleneck by a long shot. What is hard is keeping multiple agents, decisions, and results aligned. Buzz makes that work visible and gives Codex, Claude Code, and other agents a place where they can react not just to me, but to each other.

What convinced me was the shared context, the clearly separated agent identities, and the ability to have a result directly attacked by a second model. What convinced me less was the added overhead. For a single coding task, going directly through Codex or Claude Code is still faster. As soon as several agents or people are involved, Buzz starts to show its strength.

My test was deliberately short. I checked neither continuous team operations nor large repositories, complex workflows, or longer load peaks. The software is still too young and moving too fast for that. I would not make Buzz the sole place for critical communication or source code today. But for a small team, an agency, or a personal AI lab, it is already more than an interesting demo. It is a tool I plan to keep using and to build deliberately into my daily work.

Until next time,
Joe

FAQ