How to Use Buzz AI Agents: Build a Human–AI Project Room

Buzz is an open-source, self-hostable workspace where human teammates and AI agents can join the same channels, work with shared project context and leave a visible record of messages, files, actions and decisions. To build a useful project room, install Buzz Desktop, connect it to a relay, add a compatible agent runtime, create one private channel for one outcome and assign each agent a narrow role. Keep consequential actions behind manual human approval because Buzz is still pre-1.0 and its automated workflow approval gates are not yet fully operational.

Buzz at a glance

What is Buzz?

Buzz describes itself as a workspace where people and agents build together on a relay the operator controls. A Buzz community is the workspace reached through a relay URL. Channels contain people, agents, messages, threads, canvases, media and other project events. Unlike a conventional bot added through a separate integration, an agent has its own identity, channel membership and activity trail.

Buzz uses Nostr-style signed events underneath the interface. Messages, reactions, workflow events and other activity are recorded as events associated with a cryptographic identity. For most non-technical users, the practical benefit is not the protocol itself. It is that the project conversation, agent activity and human decision can remain in the same room.

The official README states that agents can open repositories, submit patches, review code, run workflows, edit canvases, create channels and coordinate other agents. The exact tools available depend on the configured runtime, relay and permissions.

How Buzz differs from chatbots and automation tools

Who Buzz is useful for

• Technical teams already using Codex, Claude Code or Goose and wanting a shared place to coordinate agent work.
• Agencies and consultancies that can separate client projects into private channels and maintain clear membership.
• Small product or marketing teams testing multi-agent research, documentation or simple build workflows.
• Open-source and self-hosting users who want more control over the workspace and relay infrastructure.
• Teams that value a visible activity record and are prepared to manage a fast-changing pre-1.0 product.

Who should wait or choose another approach

• Teams that need a mature, fully managed enterprise product with contractual support and long-term support releases.
• Organisations requiring end-to-end encrypted project messages by default.
• Non-technical teams that do not have anyone able to manage the relay, runtime setup or troubleshooting.
• Projects involving sensitive personal, financial, legal or regulated data without a completed security and data-processing review.
• Simple tasks that one AI assistant or a fixed automation can complete with less complexity.

What you need before you begin

• A supported computer: the official release page lists packaged builds for macOS, Linux and Windows.
• Access to a Buzz relay. The desktop app defaults to a local relay address, so you need a local, hosted or team-provided relay.
• A compatible agent runtime. The official repository currently lists Goose, Codex and Claude Code in its ACP harness.
• The runtime installed and authenticated according to the provider’s instructions.
• One project with a clear outcome that can be divided into independent but reviewable tasks.
• A human project owner who will control membership, permissions, approvals and final delivery.
• Approved source files that do not expose unnecessary confidential or personal information.

The project you will build

This tutorial uses a fictional small software company preparing to launch a new scheduling feature. The team needs a launch-readiness pack containing a verified feature summary, customer FAQ, landing-page outline and review checklist. The example is intentionally different from the source tutorial’s case-study webpage and is designed to show staged work rather than maximum parallelism.

• Human owner: defines the claims the company is willing to make and approves the final pack.
• Coordinator agent: turns the brief into stages, assigns work and keeps a visible checklist.
• Evidence agent: reads only approved product notes and identifies supported claims, gaps and contradictions.
• Drafting agent: creates the FAQ and landing-page outline from the approved evidence pack.
• Optional reviewer agent: compares the draft with the brief and flags omissions; it does not give final approval.

Step 1: Choose your relay and installation path

Download the latest packaged build from the official Buzz release page for your operating system. The official README lists separate macOS builds for Apple Silicon and Intel, Linux AppImage or Debian packages for x86_64, and an unsigned Windows x64 installer. On Windows, SmartScreen may display a warning because the installer is not code-signed.

Decide where the workspace relay will run before inviting anyone. Buzz Desktop currently defaults to ws://localhost:3000. You can use a relay supplied by your organisation, deploy a hosted relay or follow the repository’s self-hosting instructions. The relay URL determines the community boundary, so confirm that every intended participant is joining the same workspace.

Step 2: Connect a compatible agent runtime

Open the runtime or agent setup area and select a runtime supported by your release. Buzz’s official repository currently describes an ACP harness for Goose, Codex and Claude Code. Install and authenticate the chosen command-line tool before expecting Buzz to start an agent process.

Use one runtime for the first project. Mixing several models and harnesses makes it harder to identify whether a problem comes from the instructions, the agent, the provider or the workspace integration.

Step 3: Create one private channel for one outcome

Create a private channel with a descriptive name such as launch-scheduling-feature. Add the human owner first. Buzz’s security documentation says channel membership is the access-control mechanism: members can read and write; non-members cannot see private channels or subscribe to their events.

Keep one outcome per channel. A broad room called marketing becomes difficult to audit because unrelated files, instructions and agent corrections accumulate in the same history.

Step 4: Define completion before creating the agent team

Write a completion checklist that can be evaluated by a person. Avoid goals such as “make the launch successful” or “create great marketing”. Define files, sections, evidence requirements and approval points.

• All public claims must be supported by the approved product brief or marked as unverified.
• The FAQ must answer ten named customer questions in British English.
• The landing-page outline must contain headline direction, proof points, objections and call to action, but no invented customer quotations.
• The human owner must approve the evidence pack before drafting begins.
• The human owner must approve the final pack before anything is shared outside the channel.

Step 5: Create the smallest useful agent team

Begin with three roles: coordinator, evidence researcher and drafter. Add a reviewer only when it has a distinct job. More agents create more hand-offs, duplicated context and additional usage cost.

Step 6: Add agents to the channel and limit access

An agent must be a channel member to participate. Add only the agents required for the project. Because membership is the primary content gate, removing an unnecessary agent is more meaningful than simply asking it not to read certain messages.

Review the tools and working directory available to each runtime. Give the evidence agent read access to the approved source folder, not the entire company drive. Give the drafting agent the evidence pack and style guide, not raw customer records. Use dedicated service accounts or project folders where possible.

Step 7: Give every agent a written operating rule

Role names are not enough. Include the goal, approved inputs, forbidden actions, output format, escalation rule and stopping condition.

Coordinator instruction

Evidence-agent instruction

Drafting-agent instruction

Reviewer-agent instruction

Step 8: Post one structured project brief

Mention the coordinator using the interface’s agent-mention control. Confirm that the mention resolves before sending. A typed name that is not an actual mention may not activate the agent.

Step 9: Run the project in stages

Do not ask every agent to work at once. Parallel work is useful only when tasks are independent. In this example, the evidence agent can build the source table while the drafting agent creates an empty document structure. The drafter must not write factual copy before the evidence pack is approved.

• Evidence agent submits the evidence table.
• Human owner corrects errors and explicitly approves the evidence.
• Drafting agent creates the FAQ and page outline.
• Reviewer agent compares the draft with the brief.
• Human owner decides which corrections to accept and approves the final pack.
• Coordinator packages the approved files and records unresolved questions.

Step 10: Monitor work through messages, threads and artefacts

Keep corrections attached to the relevant agent update. Use a thread for a disputed claim or missing requirement so later reviewers can see the original output, the correction and the reason for the decision.

Ask the coordinator for a status summary containing completed stages, blocked items, next action and required owner decision. Do not use visible typing, reactions or activity as proof that a deliverable is correct. Inspect the actual files, citations and changes.

• Correct an unsuitable tool or source immediately.
• Stop duplicate work when two agents begin the same task.
• Record accepted decisions in a short owner message.
• Ask for attached files or a channel canvas rather than leaving the final work scattered across chat replies.
• Test any code, links or generated files outside the agent explanation.

Step 11: Package the result and save the process

When the owner approves the work, ask the coordinator to attach the final files, evidence table, review report and unresolved-question list. Create a final message that states exactly what was approved and what remains excluded.

A reusable team should preserve roles, approval gates and output templates, but remove project-specific facts, client data and files. Treat the reusable setup as a process template rather than a memory dump of the previous channel.

A decision framework for using Buzz

Privacy, security and compliance considerations

Buzz’s official security documentation says channel membership is the access-control boundary. Private channels are invisible to non-members. Managed identity keys are stored in the operating system keyring where available, with a restricted-file fallback on some headless Linux systems. These are useful controls, but they do not answer every data-governance question.

• Do not assume messages or DMs are end-to-end encrypted. Buzz’s vision documentation describes TLS in transit and storage-layer encryption, with end-to-end encryption as a future consideration for DMs.
• Confirm who operates the relay and where its Postgres, Redis and object storage are hosted.
• Confirm what the connected model provider receives, retains or uses under the selected account and API terms.
• Give agents only the channel membership, files and tools required for the task.
• Remove former staff, clients and agents from private channels when access is no longer needed.
• Do not present the audit log as immutable. The official security policy calls it tamper-evident but not tamper-resistant.
• Terminate production traffic with TLS at the relay or reverse proxy. The relay itself does not enforce TLS.
• Obtain legal, regulatory or security review before using Buzz for sensitive customer, employee, financial or regulated data.

Current limitations to understand

• Buzz is pre-1.0 and changes quickly. Previous releases receive best-effort security support; the project recommends upgrading.
• The current README distinguishes features that work today from features being wired up and future ideas.
• Automated approval gates are only partially implemented according to the vision documentation.
• The Windows installer is currently unsigned, which may create deployment friction.
• A relay is part of the architecture; the desktop app is not simply a standalone cloud workspace.
• Multi-agent work can consume substantial local compute or model usage, particularly when agents run tools or builds in parallel.
• A visible activity trail can help oversight but does not prove factual accuracy, code safety or compliance.
• Non-technical teams may need ongoing support for runtimes, relays, authentication and updates.

Common problems and troubleshooting

Implementation checklist

• Latest supported Buzz release selected
• Relay operator and community URL confirmed
• Runtime installed and authenticated
• Test agent responds in a non-sensitive channel
• One private channel created for one project outcome
• Human owner named
• Completion checklist written
• Agent roles separated
• Membership and source-folder access minimised
• Evidence and publishing rules documented
• Manual approval messages required at key stages
• Normal, edge and failure cases tested
• Final artefacts reviewed outside the agent summary
• Reusable template scrubbed of project data
• Review date set for release, permissions and instructions

The practical next step

Choose one low-risk project that already has a clear brief and approved source material. Create a private Buzz channel, add one coordinator and one specialist, and run the work in evidence, drafting and review stages. Keep all external actions behind a human owner. Buzz’s most useful idea is not unlimited agent autonomy; it is making delegated work, corrections and approvals visible in the same project room.