I wasn’t quite sure where best to put qualitative feedback, but I felt this was worth sharing because the early experience with Buzz was genuinely impressive—and I also ran into some fairly serious product constraints once I used it for sustained, agent-led engineering work.
My goal was to use Buzz to abstract away some of the coordination layers in my development pipeline. I set up:
- A main orchestration agent running a more capable/expensive model
- A verification agent
- An implementation agent
- A research agent
I created a project, added channels for each work lane, and added the relevant worker agent plus the coordinator/orchestrator to each channel. At least from my reading of the product, that seemed like the intended model.
Initially, it worked brilliantly. Agent coordination felt smooth, wake-ups happened when they should, and the agents were handing work back and forth through the channels in a way that felt surprisingly close to the “multi-agent engineering team” dream. For the first few hours, I was extremely impressed.
Then I looked at my usage.
Quite closely.
With a small amount of fear.
I found two main issues—one partly caused by my own setup, and one that feels more fundamental to how Buzz currently manages channel context.
1. My setup amplified orchestration costs
Because the orchestrator was present in and managing its own channel while also receiving replies in the work-lane channels, it was effectively getting pulled into more conversations than I initially realized.
That caused usage to compound quickly. This is partly on me: I likely designed the topology in a way that let the coordinator repeatedly re-engage when it did not need to. Some clearer guidance or guardrails around recommended agent/channel architecture would still be very valuable here, especially for people building multi-agent workflows with expensive models.
2. Long-running channels appear to create runaway context costs
The larger issue was channel context growth.
As channels accumulated replies, agent handoffs, and back-and-forth discussion, the context sent with each new message became enormous. In my case, I was seeing roughly 2.5 million tokens per message being sent to a model with a 1 million-token context window.
That translated into something like 8–12% of a Claude Max Ultra five-hour allowance per turn. Over roughly two days and a few hours of usage, this consumed the weekly allowance across:
- One Claude Max Ultra subscription
- One Claude Max subscription
- One ChatGPT Pro subscription
That makes the current setup very hard to sustain for autonomous engineering workflows—unless Buzz is also quietly trying to promote a four-day weekend by limiting me to a two-day work week.
I tried a few mitigations:
- Using more ephemeral channels to keep context sizes under control
- Having the orchestrator programmatically create channels from templates
- Trying the experimental session-scoped threads option
Ephemeral channels helped with context cost, but became cumbersome operationally. Once there are many tasks and handoffs, it becomes difficult to track where work happened, what decisions were made, and which channel contains the relevant history.
Session-scoped threads helped in a different way, but introduced another problem. Threads still became long very quickly when agents corresponded heavily within them. More importantly, once work is split into isolated threads without shared channel context, the core value proposition starts to fade: agents lose their common understanding of the workstream, and the experience begins to resemble managing a collection of standard Claude sessions.
Thread management also became difficult in practice:
- Threads do not appear to reorder by recent activity
- They do not have meaningful titles
- Tracking task state across multiple threads becomes increasingly manual
- The navigation overhead grows quickly in a busy autonomous workflow
What I think would help
I think Buzz needs stronger first-class context-management primitives for long-running agentic work. A few ideas:
- Configurable channel memory policies, such as “last N messages,” token budgets, rolling summaries, or selective retention
- Automatic summarization and compaction of older channel history
- A distinction between shared project memory and active conversational context
- Better visibility into what context will be sent before an agent runs, including estimated token cost
- Usage/cost guardrails, warnings, or hard limits at the channel and agent level
- Recommended multi-agent topology patterns, particularly for orchestrators that should observe, delegate, and intervene without absorbing every reply
- Better thread/task management, including titles, recency ordering, status, ownership, and links back to parent channels
- A way for agents to persist durable decisions, requirements, and task state without repeatedly carrying entire conversation histories forward
I want to stress that I’m sharing this because the initial experience was so promising. The coordination model, wake-ups, and early agent collaboration felt genuinely great. But without better controls around context growth, visibility, and thread/task organization, I can’t currently make the workflow economically sustainable at the scale I was trying to use it.
If the team—or other users—has a recommended pattern for managing context in heavy autonomous, agent-led engineering workflows, I would genuinely love to hear it. I’d be happy to give Buzz another serious attempt with a more sustainable architecture.
I wasn’t quite sure where best to put qualitative feedback, but I felt this was worth sharing because the early experience with Buzz was genuinely impressive—and I also ran into some fairly serious product constraints once I used it for sustained, agent-led engineering work.
My goal was to use Buzz to abstract away some of the coordination layers in my development pipeline. I set up:
I created a project, added channels for each work lane, and added the relevant worker agent plus the coordinator/orchestrator to each channel. At least from my reading of the product, that seemed like the intended model.
Initially, it worked brilliantly. Agent coordination felt smooth, wake-ups happened when they should, and the agents were handing work back and forth through the channels in a way that felt surprisingly close to the “multi-agent engineering team” dream. For the first few hours, I was extremely impressed.
Then I looked at my usage.
Quite closely.
With a small amount of fear.
I found two main issues—one partly caused by my own setup, and one that feels more fundamental to how Buzz currently manages channel context.
1. My setup amplified orchestration costs
Because the orchestrator was present in and managing its own channel while also receiving replies in the work-lane channels, it was effectively getting pulled into more conversations than I initially realized.
That caused usage to compound quickly. This is partly on me: I likely designed the topology in a way that let the coordinator repeatedly re-engage when it did not need to. Some clearer guidance or guardrails around recommended agent/channel architecture would still be very valuable here, especially for people building multi-agent workflows with expensive models.
2. Long-running channels appear to create runaway context costs
The larger issue was channel context growth.
As channels accumulated replies, agent handoffs, and back-and-forth discussion, the context sent with each new message became enormous. In my case, I was seeing roughly 2.5 million tokens per message being sent to a model with a 1 million-token context window.
That translated into something like 8–12% of a Claude Max Ultra five-hour allowance per turn. Over roughly two days and a few hours of usage, this consumed the weekly allowance across:
That makes the current setup very hard to sustain for autonomous engineering workflows—unless Buzz is also quietly trying to promote a four-day weekend by limiting me to a two-day work week.
I tried a few mitigations:
Ephemeral channels helped with context cost, but became cumbersome operationally. Once there are many tasks and handoffs, it becomes difficult to track where work happened, what decisions were made, and which channel contains the relevant history.
Session-scoped threads helped in a different way, but introduced another problem. Threads still became long very quickly when agents corresponded heavily within them. More importantly, once work is split into isolated threads without shared channel context, the core value proposition starts to fade: agents lose their common understanding of the workstream, and the experience begins to resemble managing a collection of standard Claude sessions.
Thread management also became difficult in practice:
What I think would help
I think Buzz needs stronger first-class context-management primitives for long-running agentic work. A few ideas:
I want to stress that I’m sharing this because the initial experience was so promising. The coordination model, wake-ups, and early agent collaboration felt genuinely great. But without better controls around context growth, visibility, and thread/task organization, I can’t currently make the workflow economically sustainable at the scale I was trying to use it.
If the team—or other users—has a recommended pattern for managing context in heavy autonomous, agent-led engineering workflows, I would genuinely love to hear it. I’d be happy to give Buzz another serious attempt with a more sustainable architecture.