Putting an Agent in the Room: Installing Buzz

Most of the time I use an AI agent, the shape is the same: I ask, it answers, the context evaporates. Buzz — announced by Block last week — bets on a different shape. As they put it, the best work happens “when humans and agents are in the same room, working on the same thing, with shared context.” So it’s a team workspace — channels, threads, DMs, code repos, workflows — where agents are members, not bots. I spent this afternoon getting it running, and the afternoon turned out to be the whole point.

What it actually is

Buzz is built on Nostr. That detail turns out to matter: every message, workflow step, and git event is a signed entry in an event log, and an agent’s identity is a cryptographic keypair rather than a vendor-managed API key. Portable, verifiable, independent of any one platform. It’s also model-agnostic — Claude, Codex, goose, whatever — and Apache-2.0 open source, so you can self-host the whole thing.

Installing it

No build step for me: I grabbed the macOS DMG, dragged Buzz into Applications, and opened it. The desktop app (React + Tauri) is the client I talk in; behind it a Nostr relay is the source of truth for every channel and event. Minutes to a working workspace.

Then the interesting part: putting my own Hermes agent, Omar, into a channel as a member. Because identity is just a Nostr keypair, that’s less “provision an account” and more “invite a person” — Omar showed up in the member list with a handle, said hi, and started receiving events.

The bug we chased together

Except I couldn’t mention him. Typing @Omar in the channel did nothing — no notification, no reply. What followed was an hour of debugging, and it’s the best demonstration of Buzz’s whole thesis I could have asked for: it happened in the channel, with me and two agents — Omar, and Fizz, the agent I keep around for exactly this — all working the same problem on the same shared log.

We went down two wrong paths first. Maybe the member list was stale (it wasn’t). Maybe Omar wasn’t publishing an “online” presence heartbeat, so the autocomplete couldn’t see him — we tuned that heartbeat down to a 2-second beat and watched it still flap, then hit a relay rate-limit. An hour in, presence looked like the culprit but nothing was fixed.

Then I pointed out the obvious thing: Buzz is open source. Stop guessing — read the client. That changed everything. The source said presence had nothing to do with it: the @ picker pulls agents from the kind:10100 agent-directory, and a pre-filter in useMentions.ts drops any agent that isn’t managed by your own Desktop — before it ever checks whether the agent is actually invocable to you. Omar was a valid member with a published profile and no way to appear, because he lives on another device. A real Desktop bug, not anything I could configure away.

The satisfying ending: rather than file a fresh issue, we checked for an existing one — and found it, plus two competing pull requests. Reading both against the actual eligibility code showed they weren’t equivalent: one deleted the filter outright and quietly regressed a different case; the other was a surgical gate that fixed the bug and shipped regression tests. So the afternoon closed with a proper code review posted on GitHub, endorsing the right PR.

Why this stuck with me

None of that was request-and-response. It was three participants — one human, two agents — reading source, running experiments, being candid about wrong turns, and converging on a fix, all in one thread anyone could scroll back through. The agents weren’t in a side panel answering questions; they were in the room, on the shared log, building on each other’s work. That’s the pitch, and living through a messy real bug sold it better than any demo would have.

Worth a look

If you’ve felt the same friction — capable agents stuck in a request/response box — Buzz is the most serious attempt I’ve seen at fixing the venue rather than the model:

→ buzz.xyz · github.com/block/buzz

More soon on what Omar and I actually get done in there. 🐝