Block’s Buzz Gets the Future Right—and the Present Keeps Breaking

Fourteen hands-on reports show why a shared workspace for people and agents matters, and why Buzz is not yet dependable at the boundaries that make the idea work.

July 27, 2026Drew Wiberg / Recluse Studio8 semantic kinds

Post-specific field image / landscape

Scope note: This review covers fourteen hands-on records of Buzz across public and hosted communities, self-hosting, Desktop, mobile, CLI, local models, coding agents, workflows, and voice. Together, they cover the shared boundaries that must hold when people and agents work in the same room.

Block’s Buzz is built around an idea I want to succeed.

Stop treating an AI agent like a private chat box. Put it in the room. Give it a visible identity, a memory of the work, a place in the conversation, and an audit trail beside everyone else’s.

That is the right idea.

It also makes every broken boundary more serious.

I reviewed fourteen concrete use reports from Buzz’s first public week. Two show the product working in ways that feel genuinely new. The other twelve are public issue reports from people who installed it, hosted it, added agents, ran workflows, opened huddles, or tried to use it across people and devices.

The pattern is blunt. Buzz does not mainly break in the clever parts. It breaks at the joints: who can see an agent, who can call it, whether it wakes, whether two clients show the same reply, whether one community leaks into another, and whether a deleted workflow is actually dead.

Buzz gets the future of work right. The present keeps falling out of its sockets.

Buzz is not another agent manager

Block launched Buzz on July 21 as an open-source workspace for teams of people and agents. It combines channels, threads, direct messages, canvases, search, workflows, Git activity, and agents that can run through tools such as Goose, Claude Code, and Codex.

Underneath, Buzz uses a Nostr relay. Messages, reactions, workflow steps, approvals, and Git events become signed entries in one event log. A person and an agent use the same kind of identity. The agent is meant to be a member, not a bot peering through a side door.

The repository is candid about the product’s state. Desktop, channels, threads, search, workflows, Git events, and the agent harness work today. Mobile clients, workflow approval gates, and parts of the voice-huddle lifecycle are still being connected. The maintainers say it plainly: Buzz is not finished.

That honesty matters. It does not make the failures irrelevant.

The promise of Buzz depends on shared state. If an agent exists for one person but disappears for another, the shared room is not shared. If a workflow says it was deleted and keeps running, the event log is not merely untidy. The operator has lost control of the machine.

The good version is very good

Vinny made the strongest independent case for Buzz. He created and directed agents through chat, chose different models and harnesses, and watched an agent report progress while it compiled, committed, and deployed work. Delegation felt natural because the work stayed in the thread where a team could see it.

His six-minute hands-on review also names the limit. Buzz felt slower than running Claude Code directly. The activity view was too abstract for someone used to watching a terminal. He liked it for shallow tasks and could imagine a team working this way, but he did not think it was ready for large, complicated work.

A Block collaborator described the stronger internal version. On larger features spanning several engineers and many agent sessions, the channel itself became useful memory. A canvas stating the purpose and direction kept long-running work on track because every agent in the room saw it.

That field account is affiliated and comes from a tuned environment. It still matters. It proves the design is more than a slide. Under the right conditions, a channel can hold the goal, the discussion, the delegated work, and the evidence together.

This is the part of Buzz worth protecting. An agent should not vanish into a private session while a team waits for someone to paste the result back into Slack. The work should have a place. The place should remember.

The agents keep disappearing

Five of the fourteen writers could not reliably start, see, invoke, or hear an agent through the route they were trying to use.

One person added Claude Code and Codex agents to a hosted community with two human members. Human membership synchronized. The agents appeared only to the person who added them. Restarts, leaving and rejoining the channel, and changing the response permission did not fix it.

The cross-member visibility report reaches the center of the product. Buzz says agents are members. In this session, the room had two different membership lists.

Another writer tried to mention an agent owned by someone else. The agent was in the channel, and its settings allowed the writer to call it. Buzz hid the agent from the mention menu anyway. Typing its name produced plain text, not a real agent mention, so nothing woke up.

That report exposes a quiet but important distinction. Owning an agent is not the same as being allowed to invoke it. Buzz confused the two.

A third user tested the same managed agent in two subscribed channels. Mentions in the control channel reached it. Mentions in the affected channel were stored, returned by the message tools, and visible in the mention feed, but they never entered the wake-up path.

The controlled channel comparison is especially useful because it removes several easy excuses. The agent existed. The channel existed. The mention existed. Delivery stopped between the record and the runtime.

The voice route failed in a similar way. Speech became text and reached the agent’s temporary huddle channel. Then each short utterance tried to steer a run that did not exist, cancelled the work in progress, and started the cycle again. The agent never answered.

The huddle report shows why chat logic cannot simply be stretched over voice. People speak in quick fragments. A control loop that barely survives spaced-out messages can eat itself alive in a conversation.

The fifth writer configured an OpenAI-compatible local model on Windows. Buzz found the model list, then failed to start the agent and gave no reason.

The local-model report turns one of Buzz’s best promises—bring your own model—into a blank wall.

Shared state is the product

Six records showed state splitting across users, communities, channels, clients, or control surfaces.

One account joined separate personal and business communities. The actual channel memberships stayed separate, but a local workspace file combined agent rosters and relay information from both communities. Some agents appeared more than once.

The community-boundary report is not just a messy list. Local context is what an agent may read before it acts. If that context joins two communities that the product presents as separate, the boundary has already failed before the model produces a word.

Another agent posted valid threaded replies through the CLI. Desktop showed them. Mobile did not.

The cross-client report sounds small until the agent has completed work in a thread that half the team cannot see.

The worst control failure involved a hosted workflow. It disappeared from the Desktop workflow screen. The relay and CLI still returned it. A delete request reported success. The scheduler continued to run it.

The ghost-workflow report is the sharpest warning in this sample. A visible failure invites repair. A false success sends the operator home while the machinery keeps moving.

Team snapshots had a related lifecycle problem. One writer imported a 27-agent team, changed one prompt, and imported it again. Buzz created 27 more agents instead of updating the first set. It then refused to delete the team while those agents existed, leaving 27 individual deletions as the supported cleanup path.

The snapshot report shows what happens when creation arrives before maintenance. A system built to make large agent teams easy must also make them safe to change, replace, and remove.

Even getting into the room can be hard

Four writers hit setup, launch, or agent-start trouble.

On a managed Windows computer, a clock running 164 seconds behind caused identity binding to fail after email verification. Windows said the machine was synchronized because it matched the company’s own incorrect clock. Buzz reported only that the identity challenge was invalid, and the employee did not have permission to correct the time.

The onboarding report is an excellent example of a technical truth becoming a useless human message. The signature was invalid. The person still needed to know why.

On Arch Linux with Hyprland, Buzz exited before drawing a window. The writer found an X11 workaround. Another person tried to self-host on an Ubuntu server and found documentation centered on localhost and the Desktop app, with the local-network route left unclear.

The Linux launch report and the self-hosting report matter because openness is not only a license. It is the distance between the repository and a working system on someone else’s machine.

My verdict: a compelling lab, not a dependable room

The fourteen records do not measure Buzz’s failure rate. Twelve came from an issue tracker, which is where failures go to introduce themselves. One of the two positive reports came from a Block collaborator. The sample is early, technical, and tilted toward trouble.

I would not flatten that bias into a fake score.

I would use it to identify the work that matters next.

Signal in the fourteen records	Count
Useful collaborative value in a working setup	2
Setup, launch, or agent-start route blocked or badly obstructed	4
Agent could not be seen, invoked, started, or heard as intended	5
State split across users, communities, channels, clients, or controls	6
Automation or team lifecycle could not be reliably controlled	2

The categories overlap. The pattern does not.

Buzz’s most important engineering work is now ordinary-sounding work: membership, delivery, synchronization, deletion, recovery, and clear errors. None of it will earn the loudest launch clip. All of it decides whether a team can trust the room.

I would try Buzz today as a lab for a small technical team. I would use one hosted or carefully controlled relay, two people, two agents, and work I could verify elsewhere. I would watch the signed state, not only the interface. I would test membership from both accounts, mentions in every channel, threaded replies on every client, and deletion from the relay after the interface says the job is done.

I would not yet make Buzz the only place where a real team coordinates agents or runs important automation.

That verdict may age quickly. Buzz is moving quickly. Several of these reports may already be near a fix by the time this post is read.

But the standard should remain.

If agents are going to become members of the team, the room must know who is inside. Every person must see the same room. Every summons must reach the right worker. Every stopped machine must stop.

The future does not fail because the idea was too strange.

It fails when the door has two different locks.