For a long time, the operating model was shaped by the popular tools of the time. Asana, Jira, and Linear encoded sprints, weekly planning, and Kanban into a ritual companies could systematically implement to drive processes. The tools shaped the operating model and the operating model shaped the tools. This wasn’t the best operating model, just the best model the current tools could support. When the tool becomes something as configurable as Buzz, those constraints go away. Now the operating model needs to catch up to the capabilities supported by the tool.
When a thread in Buzz becomes the diagnosis, task, fix, and conversation of the issue it condenses what used to take different tools into one thread anyone can follow. It’s the entire context a user can follow to understand why a decision was made. There are also CLI commands for everything in Buzz, allowing agents to create their own channels, update their own memories, and take other user-level actions. Users can adjust the behavior, tools, models and harness powering each agent while setting up channel specific or thread specific rules for agents to follow. If that’s not enough, the app is also open source so users can modify, improve on, or contribute back to making Buzz the standard interface for work.
Buzz is so configurable the question isn't can it do this or that, but how do you set it up to do exactly what you want. I’ve been experimenting with agents that produce a whiteboard for every thread and share it amongst all agents working in that thread. It produces better context handoffs with no additional work on my end because the rules of engagement are defined in the channel. There are so many more ways to experiment.
With so much flexibility, the bottleneck becomes the operating model. How do you orient your rhythms and processes to maximize output with the tools available? What’s the value of a project tracking tool when users can track the task as a thread directly in Buzz? What needs tracking when it’s all captured in the thread by humans and agents?
The limiting factor is no longer the speed at which a user can copy and paste from one tool to the next. We’ve been experimenting with this for a few months now and have yet to figure out the operating model that maximizes the value of Buzz for an organization. Working on Buzz with Buzz has introduced a new set of questions we would not have asked before: What is the right collaboration model between agents? How does this change for non-engineering work? What is the best level of abstraction for agents to work well effectively? How do you define how a team of agents collaborates well without you? If agents can spin up their own channel and invite other agents only, how far can a team push the envelope on automation?
Personally, it’s been awesome working on coming up with new ways to collaborate. The most obvious thing is how much we still need to try.
So much of our work is collaborative and that doesn’t need to stop with AI. Come up with new ways to work with Buzz as the interface and coordination layer that brings it all together - buzz.xyz / github.com/block/buzz
