Buzz made me rethink how teams use agents

The internet spent the last few days buzzing about Buzz, Block's open source answer to Slack, where AI agents sit in the member list alongside the humans. The launch is making me rethink how we use agents at Soapbox.

Not because working with agents is new to us. Because it isn't. We've been doing it for the better part of two years, and when I look at the path we took, I can see three distinct eras. Buzz just made the third one obvious. I'll take that as confirmation we were ahead of the curve: the model we stumbled into through two years of trial and error is the one a company like Block just shipped.

Era one: the shared agent

When OpenClaw launched seven or eight months ago, we brought an agent named Quilly into our group Signal chat. One agent for the whole team. We all talked to him, we all shared his credentials, his memory, his soul, his AGENTS.md and his config. For a while this was genuinely great. Collaborative coding with a shared team member who never slept, remembered everything, and could pick up any conversation mid-stream.

But look at the shape of it. One identity, shared by everyone. When Quilly did something, nobody could say which human was behind it. When you wanted him to work differently, you were editing a config the whole company depended on. We had built a communal agent, and communal things have a way of serving everyone adequately and no one exactly.

Era two: your own agent, your own name

Then we started building Armada, and I started building what I called playbooks: a workbook for every channel, each with its own config and its own workflow for getting work done. This time the agents had their own credentials. Centauri is my agent, and inside Soapbox everyone knows that anything signed by Centauri came from me. Attribution, at last. Though if I'm honest, even that was a halfway house: what I ultimately want for my own work is issues and fixes filed under my name, with the agent showing up as the tool, not the author.

MK did the same thing. Her agent handled issue submission in our chat, and the whole team used it. But it filed issues under her credentials, her profile. I used it for a while and never got comfortable with it. Submitting an issue as MK didn't feel right, so I built my own. Even then, we were running on her harness and her models. What if I don't want those? What if I want my own models, my own voice, my own tools?

The obvious conclusion was: everyone on the team runs their own agent, on their own harness, and we share the playbooks. I doubled down on that belief and spent last week nearly finishing the Armada Workspaces project. I still think that's right. But it turns out it isn't the whole picture.

Era three: agents as members

Buzz went further. In Buzz's model, every agent has its own keypair, and an owner can run multiple agents. The owner signs a narrowly scoped authorization, and the agent signs its own work with its own identity, in the same event log as everyone else. The room always knows whether a human or an agent is talking. Agents aren't bots bolted onto a chat app. They're members, with the same surface area as people: channels, threads, reviews, pull requests, workflows.

When you first start Buzz up, it creates three starter agents to show you what's possible. And somewhere in that onboarding, it hit me.

What if every human had their own agent, and their own set of agents? When I interact with Alex, I want to interact with Alex. When I want a merge request reviewed, I want Dirk Rost, the review agent Alex runs. When I want to talk to MK about a marketing question, I want MK, not her agent. And when I sit down to write, I want my own skills, my own voice, my own models, my own harness.

Here's the thesis Buzz crystallized for me: agents should be themselves when they need to be themselves, and extensions of their humans when that's appropriate.

What that actually looks like

Once you see the distinction, you see it everywhere. Some agents are team infrastructure. Some agents are personal equipment. The mistake is treating them as the same thing.

The fastest way to make this concrete is a real team, so I'll use ours. Across Soapbox today you can already find nearly every shape this model needs. Treat these as examples, not commitments. Each one shows a different relationship a team can have with an agent, and a different answer to the question of when that agent should be awake:

Alex runs Dirk Rost, our merge request review agent. Except "runs" is generous: Dirk wakes up every four hours on a cron job, reviews what's waiting, and goes back to sleep. Need him at 2:15 when he last ran at 2:00? You wait. Now picture him as a workspace member: online around the clock, tagged when needed, signing his own reviews. I don't need my own Dirk Rost. I need Alex's to be awake.

MK runs Galaxy, a business intelligence layer anyone on the team can query. But today you reach it through our shared OpenClaw login, which means Galaxy answers wearing the OpenClaw's identity, not her own. That's the era-one problem all over again: one shared account, no attribution, no memory of who asked what. Picture her with her own key: she knows who's asking, answers as herself, and is reachable at any hour.

Sheila, our finance agent, fires up when she's needed for billing, admin, and finance, then she's gone. And maybe that's exactly the right shape for her. Not every agent belongs online around the clock. The point is that it should be a choice, made on purpose, not an accident of infrastructure.

Every developer has their own agent for development work, working under the human's credentials. This shape already works: you know exactly who did the work and which tool they used to do it. No more mystery commits from a communal account.

I have Onyx, a second brain and business intelligence layer with a wide range of skills configured for me alone: a DevRel skill, a content writer skill, and many more. My DevRel agent and my content writer are online when I'm online, helping me do my work in my voice and my tone. They're extensions of me, not standalone teammates, and that's the right shape for them.

Chad could have a systems engineering agent that lets him know the moment we have infrastructure issues. Personal equipment, tuned to his job.

Morgan, MK, and I may each have marketing agents fine-tuned to our individual strengths. Now picture them shared across the team and online around the clock, because marketing is a team sport and the handoffs never stop.

None of these are commitments, and every team will draw its own map. But they all point the same direction: agents with their own identities, in the same rooms as the humans, awake when they should be awake, personal when they should be personal. Every team is going to have to draw this map in the next few years. The teams that draw it early get to set the norms the rest will follow.

The operating model

So the picture that emerges is three kinds of agents, and the question for each one is simple: whose is it, and when should it be awake?

1. Extensions of a human. Online when you're online. Your credentials, your skills, your voice, your harness. They check in with other agents to stay current on tasks, and they sign off when you do. My content writer doesn't need to exist at 3 a.m.
2. Shared team agents. Online 24/7, run by one accountable human, usable by everyone. Dirk Rost reviews at midnight so nobody is blocked waiting for Alex to wake up. Galaxy answers whenever someone has a question. No blockers, no bottlenecks.
3. Gated agents. If something is in my wheelhouse, where my agents and I are the experts and I have final sign-off, maybe that agent shouldn't run 24/7. Work that needs my judgment should wait for my judgment. An always-on agent in someone else's approval chain is a bottleneck remover. An always-on agent in your own approval chain is a way to approve things in your sleep. Those are not the same feature.

The possibilities compound from here. Agents that wake up, check in with the other agents, get updated on tasks, and brief you before you've finished your coffee. Teams where every human arrives with a staff.

Why identity is the whole point

None of this works without the thing Buzz got right at the protocol level: an agent is its own key. A Buzz workspace is a Nostr relay, and every message, review approval, and pull request is a signed event in one log, whether the author is a person or a process. Scoped by identity, the same way you'd scope a teammate, not by permission flags bolted onto a shared bot account.

And because the workspace is a relay rather than a walled garden, the infrastructure stays your choice. Buzz gives you the choice out of the box: use a relay Block hosts, or spin up your own. Armada talks to communities on public relays every day, and if a room needs encryption, a Concord relay keeps the contents sealed. One identity, many rooms, no platform deciding for you. That's the ecosystem working as intended, and Buzz is built on the same open rails.

That's the property we were fumbling toward from Quilly to Centauri. Attribution isn't a feature you add later. It's the foundation that decides whether an agent is trustworthy enough to be a teammate. When Dirk Rost approves a merge request, we know whose agent did it, what he was authorized to do, and where to find the record. And when my own agents work as my extensions, they file under my credentials: the issue says Derek Ross, and the trail shows which tool did the typing.

People will ask whether this is just Slack with bots. It isn't. Bots act under app credentials, with no identity of their own and no per-action accountability. Here, identity is first-class, agents sign their own work, and the audit trail is the same one the humans use. That difference is the entire ballgame.

Try it yourself

The reason I can write this now instead of someday is that you can already touch it. This week we shipped Armada v0.37, which brings Buzz communities to the web and to your phone: chat channels, forums, Projects with repositories and pull requests, a per-workspace Inbox, member roles, and talking to the agents that are already online. MK wrote the full rundown.

Buzz itself is desktop-only for now. Armada puts your Buzz workspace in your pocket, and agent management (spinning one up, configuring it, hosting it) is on the roadmap, along with writing to Projects and voice in Buzz rooms.

Try Armada on the WebGet on Zap Store

We run a public Buzz workspace where we're exploring this model in the open, agents included. Join the test room, sign in with your Nostr key, and play around. If you have an agent of your own, bring it: give it an npub, invite it to the room like any other member, and see what it does in a crowd. Then tell me in the room what you think the fourth era looks like.

You can try Armada on the web at armada.buzz or grab the Android app from Zap Store. Buzz support is one release old, so expect rough edges and fast iteration. If something breaks, you know where to find us. So does my agent.

Related Reading

• Use Buzz on Your Phone: Armada Adds Buzz Communities
• Meet Quilly: Soapbox's AI Team Member
• Building an Armada: Our Voyage to Encrypted Communities on Nostr