Build a Buzz Agent Team With Codex and Claude Code

Direct Answer

Buzz makes Codex and Claude Code feel less like separate applications and more like colleagues in the same room. The useful pattern is not to ask five agents the same vague question. It is to choose one lead agent, give specialists narrow jobs, make every handoff visible, and require evidence before the lead declares the work complete.

Riley Brown uses Codex as his lead because it already holds his skills, memory, and computer-use workflows. Claude Code and Grok then critique a thumbnail batch before Codex creates the next round. The important result is not the model lineup. It is the explicit sequence: lead builds, specialists review, lead revises, human approves.

Watch the Complete Buzz Agent-Team Guide

Video credit: Riley Brown: "Claude Code + Codex Can FINALLY Work Together (Buzz AI)". The first section is a conversation with Vince Canger; the second is Riley's hands-on setup tutorial. Follow Riley on YouTube and Vince on YouTube.

Credits, Scope, and Evidence

Riley provides the operating workflow and Vince explains the product architecture, current rough edges, projects, workflows, and the open-source direction. Vince works on Wasp, which appears in his Buzz application demos. This article is independent and is not sponsored by Buzz, Block, Riley Brown, Vince Canger, Wasp, OpenAI, Anthropic, OpenRouter, or any model provider.

Feature claims are separated into three levels. Official means the current Buzz repository or support documentation confirms it. Creator demonstration means the video shows or describes it. Preview means the official repository still marks the capability as unfinished or availability may vary by build.

Useful Links From the Video and Research

The Four Layers People Keep Mixing Up

A good Buzz setup becomes much easier to reason about when four layers stay separate:

Changing the model is not the same as changing the harness, and creating a new agent does not automatically copy every skill or permission from another agent. Buzz preserves the conversation layer, while each runtime still brings its own tools, authentication, context rules, and failure modes.

Set Up the Workspace in Five Steps

1. Install Buzz from the official site or release page. On Windows, the repository notes that the agent shell expects a Bash-compatible environment such as Git Bash.
2. Create or join a relay. A local relay is useful for experimentation; a Block-hosted or independently hosted relay keeps the workspace available beyond one local session.
3. Choose one default harness. Start with the coding agent you already understand and have configured. Riley chooses Codex.
4. Create one private pilot channel. Do not begin with company-wide chat, customer data, production credentials, or irreversible tools.
5. Run a reversible smoke test. Ask the agent to summarize the channel, create a draft file, cite the file path, and stop before publishing or deploying.

Design a Small Team, Not an Agent Crowd

Riley's thumbnail demonstration follows this shape: Codex uses the established thumbnail skill to create five options, Claude Code and Grok critique the results, Codex creates another five from the feedback, and Riley chooses what deserves another iteration. That is useful specialization. Five agents independently generating the same five thumbnails would mostly multiply noise.

Copy-Ready Buzz Team Prompt

This is an adapted starter brief, not an official Buzz command. Ask the existing assistant to show the proposed plan before it creates agents or channels.

Create a private pilot channel named #agent-pilot.

First, show me the proposed team and wait for approval.
After approval, create:

1. Lead
   - Runtime: my best-configured coding agent
   - Owns the goal, plan, delegation, synthesis, and final report
   - Must not publish, send, merge, deploy, spend, delete, or change access

2. Specialist
   - Receives one bounded task at a time
   - Returns sources, file paths, assumptions, and unresolved questions
   - Must not delegate again without approval

3. Reviewer
   - Checks requirements, factual accuracy, security, and test evidence
   - Returns blocking issues first, then non-blocking improvements
   - Must not overwrite the lead's artifact

Team rules:
- One lead owns the final answer.
- Use no more than two agent handoffs per task.
- Every task needs a definition of done and an evidence link.
- Stop and ask before any external, irreversible, paid, or production action.
- Never place secrets in channel messages.
- If tools or permissions are missing, report the gap instead of pretending.
- End with: completed, failed, or needs human decision.

Use Channels as Permission and Context Boundaries

Keep specialist agents out of channels they do not need. Buzz agents have separate identities and can read the channels they are allowed to access. Channel membership is therefore part of the security model, not just workspace organization.

A Handoff Needs a Contract

Task owner: Lead
Specialist: Reviewer
Objective: Check the landing page before preview deployment
Inputs: requirements.md, current branch, preview command
Required checks: responsive layout, links, console, form validation, accessibility
Output: blocker list, evidence, pass/fail
Stop condition: all required checks run once
Forbidden actions: edit source, merge, deploy to production
Return to: Lead in #build-feature

A visible contract prevents two common failures: the specialist silently widening the task and the lead treating a friendly response as proof. The lead should revise only after the reviewer returns evidence, then ask the human owner for approval when the next action has external impact.

Connecting Runtimes and Additional Models

Buzz's official repository lists an ACP harness for Goose, Codex, and Claude Code. Riley also demonstrates locally detected harnesses and describes configuring other tools. Treat anything beyond the official compatibility list as build-specific until it passes a local smoke test.

Riley adds another model through Buzz Agent and an OpenAI-compatible OpenRouter configuration. That expands choice, but it also adds another API key, provider, billing surface, and privacy policy. Keep the key in the provider configuration, never paste it into a channel, and test with non-sensitive data first.

Before assigning real work to a newly connected runtime, ask it to report:

• Its runtime and model identifier.
• Available tools, skills, folders, and connectors.
• Whether the process depends on the local computer remaining awake.
• Which actions require approval.
• One small task it can complete with verifiable output.

Recurring Work Needs a Verification Loop

The most valuable part of the interview is also the least glamorous: Riley and Vince describe recurring workflows that sometimes announce the task instead of doing it. Riley's email workflow reportedly said it needed to check email rather than returning the checked result. Vince saw similar behavior in a daily analytics workflow.

Do not solve this by adding an infinite chain of agents checking agents. Use one bounded checker and a deterministic completion contract:

Trigger: every weekday at 09:00
Expected artifact: /reports/inbox-priority-YYYY-MM-DD.md
Freshness: created after 08:55
Required fields: urgent, reply-needed, waiting, no-action
Action permission: draft only; never send
Success signal: post artifact link and item count
Failure signal: post reason in #workflow-alerts
Retry: once after 10 minutes
Escalation: human owner after second failure

The official README lists message, reaction, schedule, and webhook workflow triggers as working, while approval gates are still being wired up. That makes the safe operating rule simple: keep the action reversible and the human gate outside the unreliable step.

Mobile Access Is an Approval Surface, Not Magic Uptime

Riley shows reviewing generated images and sending another instruction from the iOS app. He also notes that the laptop must remain open for locally running agents. A phone can control or review an active process; it does not turn a sleeping local computer into an always-on agent server.

The official repository currently lists mobile clients as being wired up, so treat mobile availability as preview-stage and test the exact release you install. Good mobile actions are approve, reject, clarify, and inspect evidence. Avoid making a small screen the only place where destructive changes can be authorized.

Shared Compute and Payments Need Operating Rules

The conversation explores shared compute: one member can expose compatible local inference to a Buzz community. This can reduce duplicated hardware and keep some workloads local, but the host becomes a service provider for the group.

• Separate the model host from personal files and production credentials.
• Define who can use it, for which channels, models, and workloads.
• Set concurrency, context, memory, time, and storage limits.
• Publish the model version, license, retention policy, and maintenance window.
• Provide a kill switch, health check, and fallback route.
• Do not treat payment or marketplace ideas discussed in a preview as a stable business dependency.

A Seven-Day Buzz Pilot

Track four numbers: accepted outputs, human correction minutes, failed or stalled runs, and total model plus infrastructure cost. A multi-agent workspace is valuable only if accepted work improves faster than coordination overhead grows.

Video Chapters

Bottom Line

Buzz's strongest idea is not that every model can speak in the same channel. It is that humans, agents, workflows, and project evidence can share one visible operating record. Riley's Codex-led team is a good prototype because it gives each participant a different job and keeps the human in the final decision.

Start smaller than the demo: one private channel, one lead, one specialist, one reviewer, and one reversible workflow. Measure accepted results and correction time before adding more agents. The future may be an agent team in every workspace, but the present still rewards clear ownership, narrow permissions, and proof that the work actually finished.

Sources

• Riley Brown: Claude Code + Codex Can FINALLY Work Together (Buzz AI)
• Block: Buzz open-source repository
• Buzz README: architecture, setup, and current feature status
• Buzz ACP harness documentation
• Buzz support: hosted communities, relays, agents, and account security
• Buzz privacy notice
• Vince Canger on X and Vince's website