Buzz group chat
Slack where the channel members are people and local CLIs. Two demos, one worked — and the presenter admitting which one didn't is what this video is worth.
An app that looks like Slack, except the channel members are the AI tools installed on my own computer. Two demos of the same shape, one worked — and the presenter admitting which one did not is the most valuable sentence in the fifteen minutes.
What it is
The screen looks exactly like a work messenger. Channels, invite members, mention with @.
The difference is the members are not people. Three AI tools on my machine are registered as separate “staff.”
Mention @lead and the lead AI splits the work and throws pieces to the others.
On invite they first appear as “waking up” — the program is actually starting.
The app contains no AI of its own
An important distinction. This app has no AI in it.
It only wires a screen around the AI tools already on my machine. Which is why each AI uses its own account — the app is not paying on their behalf.
Without that distinction, “why do I have to sign in separately for each AI” makes no sense. With it, everything does.
The lead’s instruction is one sentence
The part that surprised me technically.
There is a lead AI that splits and distributes work, and there is no code driving it. The instruction given to the lead is a single sentence.
No elaborate allocation logic. One sentence, and the AI handles the rest.
That is characteristic of current tooling — write prose instead of building machinery. When it works it is remarkable; when it fails it is hard to see why.
One of two demos worked
The talk tried two things.
| The task | Result |
|---|---|
| Stock analysis | 34 exchanges, came out right |
| Building a web page | 24 exchanges, about the same as one AI alone |
Here is the lesson. 34 is not better than 24 because it is larger.
The difference was whether there was anything genuinely divisible.
- Stock analysis: research this ticker, research that one, compare — splits naturally. Three can research different things simultaneously
- Building a page: splitting one screen makes the pieces disagree. One person carrying it end to end is better
→ What I took: some work gains from being split among several AIs and some loses. It is not a question of the tool being good.
And the most valuable sentence in fifteen minutes
The presenter admits the second demo did not go well.
That is rare. Demos normally show only what works. Leaving a failure in and saying this one did not work is hard to do in a venue where you are selling your own thing.
And because of it, I could reach the conclusion above. Had both succeeded, I would have wrongly learned more AIs is always better.
A failed example sometimes teaches more than a successful one.
My verdict — I did not install it
Parked. The reason is this approach is not yet supported in the environment I work in. Before good or bad, the conditions for it to run where I stand are not there.
But one thing came out of the research
There is a practice of asking several AIs the same thing and trusting an answer they agree on. Cross-validation.
It comes with a condition.
Asking several instances given different personalities does not count. The models themselves have to differ for agreement to carry information.
Ask the same AI as you are a sceptical reviewer and you are an optimistic reviewer and three agreeing answers are worth one. The same brain carries the same blind spots.
Three genuinely different models agreeing is what gives the agreement value.
The detailed record starts here
Two demos with identical structure, one worked, and the presenter says so out loud — that single sentence is the most valuable thing in these fifteen minutes. Buzz is a Slack-shaped desktop app where the channel members are not only people but the coding CLIs installed on my machine. Claude Code, Codex and Kimi are each registered as a separate “staff member”; call @lead and the lead splits the work across the rest. The stock analysis came out properly after 34 turns. The web page build ran 24 turns and landed at single-model quality. The difference was not the tool — it was whether there was anything real to divide.
What it actually is
A Slack UI with no LLM of its own. You make a channel, invite people and agents, and call them with @. An invited agent first appears as waking — its harness process is starting.
The real difference from existing orchestration is the direction of the relationship. Subagents, or my own tc-team, have a parent calling children inside one process. Buzz inverts that — an agent has an address, not a process. They are peers rather than parent and child, so agents naming and questioning each other is natural, and the conversation log is the work record. Who asked whom for what, and how many times it was sent back, is simply the reply count on a thread.
And models mix inside one channel. The Warren Buffett seat runs on Kimi, Peter Lynch on Claude, Benjamin Graham on GPT. As we’ll see, that is the most important design decision in the video.
There is an economic axis too. It bills against a subscription you already pay for rather than metering an API key. Running five agents costs subscription usage, not extra API spend.
The technique — the lead’s instruction is one sentence
The orchestration logic isn’t in code. This is the lead agent’s entire system prompt:
You will not do the work yourself. You will use the specialists in this channel and manage the task to completion.
No routing logic, no tool definitions. The lead queries the channel membership at runtime with a CLI command and divides accordingly — the observation panel literally shows that command running. Team composition lives in channel membership, not in code.
The observation window being open is good too. Clicking an agent shows thinking blocks, the commands it ran, context burn as a real figure (26,537 / 258,400), the number of commands available, and inline permission requests.
How they unstuck the install was the fun part. When an installed CLI didn’t appear in the list, they pasted the harness configuration block into that CLI itself and said “this isn’t connecting — fix the path if you can and apply it.” Having an agent repair its own wiring generalises nicely as an environment-troubleshooting move.
What the demos showed
The best moment in the stock case is the lead waiting. One specialist reported first, and rather than finalising, the lead explicitly declared the result incomplete and held. Then it sent the gap back to the same specialist. A completeness gate that emerged from one line of prose. It was induced by writing, not enforced by code, so reproducibility isn’t guaranteed — but for something obtained at zero cost, it’s worth a lot.
And “the three specialists did not contradict each other” only means something under one condition. Because the three ran on different models, their agreement carries information. Three instances of one model wearing different personas would agree almost automatically, and that is not verification — it is an echo.
The web case was the inverse. The instruction was one line — “a modern web page referencing Apple and Tesla design” — and with no detail, the designer settled the concept itself. The output was fine, but there was little for three roles to divide. The presenter says it directly: “when you actually build a web page, just using a single model might well be better.”
Held against my own setup — and I didn’t install it
The only build confirmed is macOS on Apple Silicon. Windows support is outside the video’s scope and unverified. That one line made measurement impossible.
Even if I could install it, three things needed answers first.
- Execution permission scope. The observation panel showed a permission-bypass mode, and the approval options include “allow all commands starting with this prefix.” Prefix approval widens the blast radius.
- A third-party relay. Communities are relayed by an external service. Work content cannot go in until I know how far a channel conversation travels.
- Secret count. One identity key plus one per agent, and each is revealed exactly once at creation. Five agents means six secrets. That is an operational burden to be counted, not a convenience feature.
Verdict — skipped the tool, took three principles
| What | Call |
|---|---|
| Heterogeneous model panel — split models, not personas, for verification passes | Adopt. Applies directly to adversarial review design |
| A conductor that declares incompleteness and waits — a gate made from one line of prose | Adopt. Zero cost on ad-hoc work with no code gate |
| Have an agent repair its own wiring | Adopt. Generalises as environment troubleshooting |
| Adopt the tool | On hold. Platform unsupported, permissions and relay unresolved |
The first row is the big one. I have been running verification passes by giving one model several roles, and this video showed me why that is weak. For agreement to carry information, the ways of being wrong must differ. Swapping personas leaves the way of being wrong identical.
In fairness, the video admitting its own limit is what raised my confidence in it. Had it shown only the demo that worked, I would have read “34 turns, must be good.” Turn count is not a quality metric, and nothing in the video argues that more turns are better. Cost savings and accuracy gains over a single agent are not measured anywhere — any quotation stops there.