Buzz Did Not Solve Multi-Agent Orchestration. It Solved Agent Identity.

Direct Answer

Buzz did not make the hard parts of multi-agent orchestration disappear. It built something more foundational: a shared workspace where humans and agents have distinct identities, join the same rooms, use different harnesses, and leave signed activity in one event log.

That is not a small achievement. Identity, shared context, attribution, and a common communication surface are prerequisites for useful agent teams. But they are not the same as dependable orchestration. A production orchestrator must know which task exists, who owns it, what it depends on, whether the worker is healthy, when it should stop, how much it may spend, and what evidence counts as completion.

Watch Josh Pocock Stress-Test Buzz

Video credit: Josh Pocock: "Buzz Didn't Solve What You Think It Solved (Open Source)". Follow Josh on YouTube and X. Josh also offers a longer Buzz document through his Stride AI Academy; this article is independent and is not sponsored by Josh, Buzz, Block, or an AI provider.

The Confusion Comes From Mixing Two Layers

A group chat can carry a handoff. A model can read that handoff and decide what to do next. When the models are capable and the task is forgiving, this can look like orchestration. The distinction only becomes visible when something stalls, loops, exceeds budget, contradicts another worker, or claims completion without evidence.

What Buzz Really Solves: Identity and Shared History

The current Buzz README describes one community, one identity model, and one event log. Messages, reactions, workflow steps, review approvals, and Git events use the same signed-event shape. An agent has a separate keypair, channel memberships, profile, and audit trail instead of borrowing the human operator's identity.

That makes three operational questions easier to answer:

1. Attribution: which person or agent produced this action?
2. Scope: which rooms and context may that identity access?
3. Continuity: can the agent keep its workspace identity while the model or harness underneath changes?

Buzz's official support documentation confirms that agents have their own profiles and public keys, and can read or send only in channels they can access. This is a cleaner foundation than one all-powerful bot account posting on behalf of every worker.

What the Current Buzz Architecture Officially Supports

Buzz is an Apache-2.0 Rust project from Block. Its relay is the single source of truth. People and agents connect over WebSocket, while Postgres stores events, channels, workflows, and audit data. Redis handles fan-out and presence, and the workflow engine supports YAML-defined automation.

The repository changes quickly. For example, the current changelog includes active-turn indicators, dead-turn cleanup after a host crash, durable per-turn metrics, and other safeguards added after earlier builds. This is why the test below should be read as a useful snapshot, not a permanent verdict on every future Buzz release.

What the One-Agent and Two-Agent Demos Showed

Josh first asks an agent to research complaints about Slack and post a summary. The agent uses its harness, returns work to the channel, and exposes an activity trace with commands and token usage. After some restarting, the basic loop works.

He then places two agents in a room and asks them to communicate. They mention one another, exchange context, and eventually produce an answer. This proves the transport layer: an agent can receive another agent's message and respond inside a shared room.

It does not prove that Buzz scheduled the turns, enforced a plan, tracked a dependency, verified the result, or decided when the team was finished. The models performed the coordination through language; Buzz delivered and recorded the messages.

Why Model Conversation Is Not Dependable Orchestration

Emergent coordination can be excellent. A strong lead model may divide work, ask for revisions, and stop when the answer looks good. It is also probabilistic. The same prompt can produce an elegant handoff in one run and silence, repetition, or circular delegation in the next.

Dependable orchestration moves the critical rules out of prose and into inspectable state:

task_id: buzz-review-042
state: running
owner: research-agent
depends_on: []
deadline: 2026-08-03T14:30:00Z
budget_usd: 1.50
max_attempts: 2
heartbeat_due: 60s
acceptance_test: cited_report.json passes schema + source checks
on_failure: reassign to coordinator and notify human
on_success: request human approval

A chat message may contain all of this information, but a control plane should parse, enforce, and display it. Otherwise the system cannot reliably distinguish "working," "waiting," "stuck," "failed," and "complete."

The Four-Agent Test Exposed the Boundary

Josh assigns research, ideation, and fact-checking work across four agents using different models. Several agents respond. One goes quiet. Repeated messages fail to produce a clear status, error, timeout, or reassignment, and Josh waits about 20 minutes before manually asking for whatever output exists.

Josh also argues that the cancellation path available in the source was not reachable through the product surface he was using. Buzz's current documentation now states that cancellation and process-group termination are handled, so the fair conclusion is narrower: never infer operational control from the existence of a backend code path. Test the button, command, permission, and failure behavior a real operator will actually use.

The Invisible Workflow Is a Bigger Warning Than It Looks

In the final test, an agent creates a scheduled 9:00 a.m. research workflow. The desktop workflow view appears empty after refreshes and restarts. Josh then builds and uses the CLI, queries the relay, and finds that the workflow exists with an ID and schedule.

This is not merely a cosmetic bug. Invisible automation creates an ownership problem. If a job can run but the operator cannot see, edit, disable, or delete it from the normal management surface, the system has created operational debt.

Every recurring agent workflow needs:

• a stable ID, owner, purpose, and current version;
• next-run and last-run timestamps;
• an execution history with costs, outputs, and errors;
• a visible enable, pause, edit, and delete control;
• a failure alert and manual fallback;
• an approval rule for irreversible actions.

Claim Audit: What Is Confirmed and What Is Version-Specific

The Control Plane a Production Buzz Team Still Needs

1. Durable tasks. Store task ID, state, owner, dependencies, attempt count, and artifact links outside conversational text.
2. Leases and heartbeats. A worker owns a task for a bounded time and proves it is still alive.
3. Hard budgets. Cap time, turns, tool calls, tokens, and money per task and per workflow.
4. Bounded retries. Retry known transient errors without creating endless loops or duplicate side effects.
5. Accessible cancellation. Stop must work from the normal operator surface and terminate the full process tree.
6. Reassignment. Release stalled work and hand it to another eligible agent with the checkpoint attached.
7. Idempotency. Replayed events and retries must not send the same email, publish twice, or repeat a payment.
8. Completion verification. A separate checker validates schema, tests, citations, or business rules before success.
9. Approval gates. Humans approve sends, merges, deployments, purchases, deletions, and permission changes.
10. Observable workflow registry. Operators can find every schedule, trigger, owner, status, cost, and failure.

Buzz can be the room and event substrate underneath this design. A separate service, project tracker, or small database can hold the enforced task state until Buzz exposes the required controls directly and they pass your tests.

A Safe Seven-Day Buzz Orchestration Pilot

1. Pick a reversible task. Use research, draft content, or a sandboxed prototype with no customer secrets.
2. Create one private room. Add one human owner, one coordinator, and at most two workers.
3. Define task records. Keep state, owner, deadline, budget, acceptance test, and artifact URL in a structured table or file.
4. Limit permissions. Read approved sources, write drafts, and use isolated branches. No sending, merging, deploying, buying, or deleting.
5. Inject failures. Kill one harness, withhold one response, return malformed output, and exceed one deadline.
6. Test operations. Cancel from the normal interface, find every active workflow, pause a schedule, restart the relay, and recover the latest checkpoint.
7. Score the result. Expand only if the team can detect, stop, recover, verify, and audit failures without reading raw source or guessing what the model is doing.

Buzz pilot acceptance scorecard

Task state visible:             pass / fail
Stalled worker detected:        pass / fail
Cancellation stops all work:    pass / fail
Budget enforced:                pass / fail
Workflow visible and pausable:  pass / fail
Checkpoint recovered:           pass / fail
Completion independently tested: pass / fail
Human approval enforced:        pass / fail
Decision: expand / revise / stop

For hosted communities, remember that Buzz support documentation says messages, direct messages, and uploaded media are not end-to-end encrypted. The privacy notice also says connected third-party model providers may receive prompts and related channel context. Self-hosting changes who operates the relay; it does not remove the need to govern every model, harness, tool, and credential connected to it.

Video Chapters

1. 00:00 - The claim everyone got wrong
2. 01:22 - How the pitch escalated in six days
3. 02:28 - What is actually real: identity
4. 04:03 - Setup, settings, and runtimes
5. 09:04 - Creating agents and harnesses
6. 11:11 - The demos: one agent, then two
7. 14:40 - Did Buzz solve orchestration?
8. 16:28 - Four agents, and one goes quiet
9. 19:13 - The workflow Josh could not see
10. 20:23 - Should you use Buzz?
11. 22:16 - Free document and wrap-up

Bottom Line

Josh's critique does not make Buzz less interesting. It makes the product easier to understand. Buzz is building the shared identity, context, protocol, and event layer that agent teams need. That foundation may become more durable than a model-specific orchestrator.

The mistake is treating a room full of capable models as a finished operations system. Agents can coordinate through conversation, but production work requires enforced state and visible control when conversation fails. Test Buzz for the problem it already solves, then add the control plane your risk level demands.

Sources

• Josh Pocock: Buzz Didn't Solve What You Think It Solved (Open Source)
• Buzz official site
• Block: Buzz open-source repository
• Buzz README and current feature matrix
• Buzz architecture
• Buzz agent architecture, cancellation, timeouts, and process boundaries
• Buzz relay and ACP testing guide
• Buzz changelog
• Buzz support: relays, agent identity, privacy, and hosted communities
• Buzz privacy notice
• Josh Pocock on YouTube