The channel as memory has been a big help on larger features that span multiple engineers and many agent sessions. Someplace ad-hoc that's shared makes a real difference.
Setting the channel canvas with the purpose and vision can keep long-horizon work on track since all the agents working in there see it automatically
Buzz is a channel-driven workspace for teams of humans and their agents to work together in. It should look vaguely similar to whatever you're used to chatting with your team in. Written in Rust. Apache 2 licensed. Nostr-shaped.
To work in Buzz, I'll spin up a new channel, add my team and my agents, and start brainstorming the best way to add a feature or fix a bug. I'll send agents out to do research, they’ll report back, and then I’ll work with my team on picking the best implementation. The agents go and implement it, test it, review it in the channel with us. They even post screenshots there for us to look at.
I spent a few months building Block's original Slack-integrated agent (based on goose). It was a lot of fun and we ended up, months later, with a great tool that ships code, does research, and helps teams in the environment they actually collaborate in https://block.xyz/inside/block-rolls-out-builderbot-a-new-su...
But... Slack was not built as a place to bring your own agent, and there are serious challenges around sharing an agent in a chat environment. Should everyone have their own bot(s)? Do we need thousands of Slack apps for that to work? If not, whose auth does it use? How does parallelism work across the workspace/channel/threads? What if I want a different LLM? Harness? Something special and unique for me or my team? These are not issues exclusive to Slack, of course, and I actually really like Slack. It’s just that the setup there doesn’t easily work for large flocks of agents.
Obviously the Builderbot team and I got through this and made something that works well for us. But the experience made me want to do this kind of thing right from the beginning.
So, Buzz.
Any agent that supports ACP (https://agentclientprotocol.com/) can live in Buzz. We ship a minimal Buzz agent that I use for everything, but our team uses goose, Claude Code, Codex, and other agents. Your subscription should work in Buzz. And any LLM that can reliably make tool calls will work fine. We've even got a fun (very rough/early) mesh-llm inference setup built-in that enables you and your team to power your own agents using open models.
Agents can start channels, archive them, add users and other agents to them. Whatever you can do in Buzz, they can do too.
There’s a Buzz mobile app that lets you chat with your team and control your agents from anywhere. Your agents can run wherever as long as they can reach your team’s Buzz. Your laptop, your home server, any cloud.
Your Buzz relay, has an S3 backed git server that agents automatically get their auth and signing set up for them on. We put together a rough proof for it because I couldn't find anyone else doing git in a provably safe way that scales like S3 does https://github.com/block/buzz/blob/main/docs/git-on-object-s...
We've adopted standard Nostr message kinds and ideas and have put together a few more for agent specific functionality that we hope others mind find helpful https://github.com/block/buzz/tree/main/docs/nips
There's a lot of fun stuff in Buzz to use and try out right now. We’ve got a sprawling vision for an open source, self-sovereign, vertically integrated, multi-player agentic workspace. It's still early days and still very, very rough, but I think this is a good way to do dev together with teams and agents going forward.
This looks pretty neat, it looks like the shape of something I want to use. I'm having trouble managing my entire project, and from reading Buzz' project description, I think I understand what my issue is: a lack feature channels. I'm purely using claude-code and I use a bespoke session-wrap command at the end of every major development or as I approach 50% context window. And then in a fresh session I use a recontextualize command to figure out the trajectory of the prior work.
I think Buzz' use of channels and rooms is better, since each feature/concept has its own development pace, velocity, and history. I'll give it a shot.
Do you have any examples comparing different agent workflows vs Buzz? Would love to understand more how you foresee people using this.
For interactive agents (ie ones working with you/your team) there are two general approaches I've seen
A single agent that you work with directly. Go back and forth with. Like a teammate, message to message.
Or, an agent that leads a team of other agents. An orchestrator that you give directions to and then it delegates the work, testing, review to other agents that are in the channel. This is really why we have infinitely nesting threads. Deep threads are hard for humans to engage with, but when the agents are working with each other autonomously over the course of many hours, they're a huge help for their self-organization.
Collaborative agentic work is the future! Excited this is out in the world
The "Incident memory" story really resonated with me. So much of my org's knowledge lives in Slack! Still reading but Buzz seems like the future.
The channel as memory has been a big help on larger features that span multiple engineers and many agent sessions. Someplace ad-hoc that's shared makes a real difference.
Setting the channel canvas with the purpose and vision can keep long-horizon work on track since all the agents working in there see it automatically
quickstart (docker required): git clone https://github.com/block/buzz; cd buzz; just dev;
Buzz is a channel-driven workspace for teams of humans and their agents to work together in. It should look vaguely similar to whatever you're used to chatting with your team in. Written in Rust. Apache 2 licensed. Nostr-shaped.
To work in Buzz, I'll spin up a new channel, add my team and my agents, and start brainstorming the best way to add a feature or fix a bug. I'll send agents out to do research, they’ll report back, and then I’ll work with my team on picking the best implementation. The agents go and implement it, test it, review it in the channel with us. They even post screenshots there for us to look at.
I spent a few months building Block's original Slack-integrated agent (based on goose). It was a lot of fun and we ended up, months later, with a great tool that ships code, does research, and helps teams in the environment they actually collaborate in https://block.xyz/inside/block-rolls-out-builderbot-a-new-su...
But... Slack was not built as a place to bring your own agent, and there are serious challenges around sharing an agent in a chat environment. Should everyone have their own bot(s)? Do we need thousands of Slack apps for that to work? If not, whose auth does it use? How does parallelism work across the workspace/channel/threads? What if I want a different LLM? Harness? Something special and unique for me or my team? These are not issues exclusive to Slack, of course, and I actually really like Slack. It’s just that the setup there doesn’t easily work for large flocks of agents.
Obviously the Builderbot team and I got through this and made something that works well for us. But the experience made me want to do this kind of thing right from the beginning.
So, Buzz.
Any agent that supports ACP (https://agentclientprotocol.com/) can live in Buzz. We ship a minimal Buzz agent that I use for everything, but our team uses goose, Claude Code, Codex, and other agents. Your subscription should work in Buzz. And any LLM that can reliably make tool calls will work fine. We've even got a fun (very rough/early) mesh-llm inference setup built-in that enables you and your team to power your own agents using open models.
Agents don't impersonate you, they're authorized by you. Cryptographically provable offline.
Agents can start channels, archive them, add users and other agents to them. Whatever you can do in Buzz, they can do too.
There’s a Buzz mobile app that lets you chat with your team and control your agents from anywhere. Your agents can run wherever as long as they can reach your team’s Buzz. Your laptop, your home server, any cloud.
Your Buzz relay, has an S3 backed git server that agents automatically get their auth and signing set up for them on. We put together a rough proof for it because I couldn't find anyone else doing git in a provably safe way that scales like S3 does https://github.com/block/buzz/blob/main/docs/git-on-object-s...
We've adopted standard Nostr message kinds and ideas and have put together a few more for agent specific functionality that we hope others mind find helpful https://github.com/block/buzz/tree/main/docs/nips
There's a lot of fun stuff in Buzz to use and try out right now. We’ve got a sprawling vision for an open source, self-sovereign, vertically integrated, multi-player agentic workspace. It's still early days and still very, very rough, but I think this is a good way to do dev together with teams and agents going forward.
Happy to answer questions and chat here.
https://github.com/block/buzz
This looks pretty neat, it looks like the shape of something I want to use. I'm having trouble managing my entire project, and from reading Buzz' project description, I think I understand what my issue is: a lack feature channels. I'm purely using claude-code and I use a bespoke session-wrap command at the end of every major development or as I approach 50% context window. And then in a fresh session I use a recontextualize command to figure out the trajectory of the prior work.
I think Buzz' use of channels and rooms is better, since each feature/concept has its own development pace, velocity, and history. I'll give it a shot.
Do you have any examples comparing different agent workflows vs Buzz? Would love to understand more how you foresee people using this.
For interactive agents (ie ones working with you/your team) there are two general approaches I've seen
A single agent that you work with directly. Go back and forth with. Like a teammate, message to message.
Or, an agent that leads a team of other agents. An orchestrator that you give directions to and then it delegates the work, testing, review to other agents that are in the channel. This is really why we have infinitely nesting threads. Deep threads are hard for humans to engage with, but when the agents are working with each other autonomously over the course of many hours, they're a huge help for their self-organization.