Buzz Agent Workspace: Build, Deploy, and Automate With an AI Team

Direct Answer

Buzz is compelling because it treats an AI agent as a participant in the workspace rather than a bot bolted onto team chat. A person and an agent can share a channel, project history, Git activity, workflow events, and the same visible audit trail. The runtime underneath that agent can be changed without moving the whole working conversation to another product.

Watch the Full Buzz Walkthrough

Video credit: Andrew Warner and Vince Canger: "Holy smokes: this agent is amazing!" The episode is from The Next New Thing. Follow Andrew Warner, Vince on X, and Vince on YouTube.

Credits, Sponsorship, and Evidence

Vince Canger is a founding developer relations engineer at Wasp, the framework used in the CRM demonstration. The episode is presented by Zapier and includes a Zapier MCP segment. This article is independent and is not sponsored by Buzz, Block, Wasp, Railway, Zapier, or any model provider.

Claims below are graded in three ways. Official means the current Buzz repository or support documentation says the feature exists. Creator demonstration means Andrew and Vince showed it in this episode. Preview means availability or reliability may differ by build, platform, account, or release.

Useful Links

How the Buzz Stack Fits Together

People and agent identities
        |
        v
Buzz channels, DMs, projects, workflows, Git events
        |
        v
Buzz relay and shared event history
        |
        v
Selected agent runtime
Claude Code | Codex | Goose | OpenCode | compatible adapters
        |
        v
Model + tools + repository + approved external services
        |
        v
Result, evidence, status, review, and decisions return to Buzz

The official repository describes the relay as the source of truth. Messages, reactions, workflow steps, approvals, and Git events use signed events. Agents have their own identities and channel memberships. That is a more useful mental model than "chatbot inside Slack": Buzz is trying to make the room itself the project memory.

Default Agents and Swappable Runtimes

The demo begins with Fizz, Honey, and Bumble. Their names are less important than their separation of responsibilities. One can be the stronger builder, another a lower-cost researcher or organizer, and another a communicator. Each agent receives instructions and is attached to a runtime.

Vince demonstrates Claude Code and discusses Codex, Cursor, Groq, Kimi, OpenClaw, and OpenCode options. The official repository explicitly lists an ACP harness for Goose, Codex, and Claude Code. Other adapters and model choices should be checked against the release currently installed.

A runtime switch should include a small continuity test. Ask the replacement runtime to summarize the project, list unresolved decisions, identify its available tools, and complete one reversible task. A shared conversation does not guarantee identical permissions or behavior.

Shared Compute Is Powerful Infrastructure

Buzz can expose a compatible local model running on one community member's machine so other members can invoke it. This can make good hardware useful to a small team and keep some inference under local control.

It also creates a provider relationship inside the team. The host machine processes other people's prompts, carries the reliability burden, and can become a bottleneck. Define these controls before sharing compute:

• Approved users, channels, models, and task types.
• Prompt and output logging, retention, and inspection policy.
• Per-user concurrency, memory, context, and time limits.
• Network isolation from personal files and production systems.
• Model name, version, license, checksum, and update process.
• A kill switch, health check, and cloud fallback.

Connected Tools Need Narrow Permissions

Andrew uses the sponsored Zapier MCP segment to explain a sensible boundary: an agent may read email and create drafts without being allowed to send. The same pattern applies beyond Zapier.

What the Wasp CRM Build Actually Proved

Vince asks Fizz to create a simple CRM with Wasp and deploy it to Railway. The agent checks the environment, notices expired Railway authentication, asks Vince to log in, continues the build, runs tests, deploys the application, opens it in a browser, signs in, verifies the main path, and returns the URL and screenshots.

Wasp is a useful fit for this kind of task because it provides an opinionated full-stack layer over React, Node.js, Prisma, authentication, jobs, and deployment. The agent spends less context reconstructing common infrastructure and more time on the application-specific workflow.

Mobile Access, Projects, and Git

The episode shows a mobile Buzz client with channels and threads, making it possible to inspect work and respond to an agent away from the desktop. The official repository, however, lists iOS and Android clients as being wired up. Treat mobile as preview functionality whose availability can vary by build.

Projects connect the conversation to code. Vince shows repositories, remote hosting information, and work happening in separate folders so the agent does not overwrite the developer's active checkout. Buzz can connect to GitHub or use the Git hosting associated with its relay.

Isolation prevents agents from editing the same files at the same moment. It does not prevent incompatible architecture, unsafe migrations, or two plausible changes that should not both merge. Keep branch protection, automated checks, independent review, and human approval.

The Workflow Engine Turns Chat Into Cadence

Vince's tweet dashboard posts daily performance data into a channel. A workflow notifies him, and the agent turns current results into safe, medium, and experimental ideas for the next post. The important shape is:

Trigger: schedule, message, reaction, or webhook
  -> filter: only the relevant event
  -> action: notify, react, call webhook, or involve an agent
  -> evidence: post the result into the channel
  -> review: human approves consequential action

The official README lists YAML workflows with message, reaction, schedule, and webhook triggers as working. Vince also says he experienced setup problems before updating. That combination calls for monitoring: every recurring workflow should have a last-run timestamp, expected output, failure alert, and manual fallback.

Multi-Agent Routing Without Theater

Vince describes using a cheaper agent to gather or sort data, a stronger model to analyze it, and a cheaper model again to format the result. The idea is sound, but only when the handoffs are explicit.

Avoid recursive delegation where agents keep inventing more agents. Use a fixed task budget, a maximum number of handoffs, one owner, and a stop condition. Measure cost per accepted result, not token savings in one isolated step.

Buzz vs Slack, Telegram, and GitHub

Andrew's strongest framing is that Buzz may first replace Telegram as the place people talk to agents, not Slack as the place the entire company already works. Buzz provides threads, human collaborators, agents, workflows, and project context in one interface without requiring a full company migration on day one.

A Seven-Day Buzz Pilot

1. Choose one reversible project. Use a prototype, research room, or internal dashboard without customer data.
2. Create one private channel. Add the goal, approved sources, definition of done, budget, and forbidden actions.
3. Add one agent. Give it one runtime and the minimum filesystem and service access required.
4. Run one build. Require a branch, tests, preview, evidence, and a list of unresolved risks.
5. Add one workflow. Use a daily status or webhook trigger with a visible last-run timestamp and failure alert.
6. Test continuity. Switch the runtime and ask it to explain current state before touching files.
7. Review the week. Score accepted outputs, human review time, missed runs, permission friction, cost, and recovery.

Buzz pilot scorecard

Tasks attempted:                 __
Accepted without major rework:   __
Scheduled runs delivered:        __ / __
Runtime continuity test:         pass / fail
Human review minutes:            __
Agent and infrastructure cost:   __
Security or privacy incidents:   __
Decision: expand / revise / stop

Keep Slack, GitHub, and the current system of record during the pilot. Buzz should earn a larger role through reliable work and recoverable failures, not through novelty.

Video Chapters

1. 00:00 - Buzz overview
2. 00:45 - Default agents
3. 03:36 - Bringing a Claude subscription
4. 04:48 - Agent runtimes
5. 05:06 - Shared compute
6. 06:45 - Zapier MCP
7. 08:24 - Building a Wasp CRM
8. 10:21 - Mobile app
9. 11:15 - Projects and Git
10. 14:15 - Why Vince uses Wasp
11. 15:27 - Workflows
12. 17:24 - Workflow actions
13. 19:30 - Multi-agent collaboration
14. 20:33 - Buzz vs Slack

Bottom Line

Buzz's most useful idea is not that one more app can call Claude or Codex. It is that the room can become the operating context: people, agents, project history, workflow events, Git activity, evidence, and review in one place.

The CRM build and daily workflow show why that matters. Work leaves the chat, touches real tools, returns with evidence, and stays attached to the project. The remaining challenge is operational trust. Permissions, provider terms, encryption, workflow reliability, backups, export, runtime continuity, and human approval decide whether Buzz becomes infrastructure or remains an exciting preview.

Sources

• Andrew Warner and Vince Canger: Holy smokes: this agent is amazing!
• The Next New Thing
• Block: Buzz repository
• Buzz README and current feature matrix
• Buzz support: relays, agents, security, and hosted communities
• Buzz privacy notice
• Wasp official site
• Wasp repository
• Railway
• Zapier MCP
• Andrew Warner on X
• Vince Canger on X