Patrick uses one model for pretty much everything. Luna Max does the day-to-day work. The exception is design. He finds GPT models weak at design, so every so often he wants Claude to look at an interface.
The key words there are "every so often." He doesn't want to move a whole project into a Claude session just to get an opinion on a layout. He wants to call a designer in, hear what it has to say, and let the main agent keep going.
That sounds easy until you ask where the designer's answer goes. Open a second terminal, or a second thread, and now you have two conversations to manage. You can copy the advice from one into the other, but congratulations, you're now the glue between two agents. Patrick wanted a place where the specialists could see the same problem, see each other's answers, and talk in one conversation.
That became Bot Teams, a plugin for BB. The first channel he set up is called Command Center.
Bots in a group chat aren't new. People already put agents in Slack and Discord. Hermes Bot Mode already has persistent bots and group conversations. What Patrick wanted to try was putting the group chat inside the agent workbench, with BB's threads, models, tools, and permissions underneath it.
First there was Council
Before Bot Teams there was Council. The idea came from the Magi in Evangelion: minds with different points of view, all looking at the same question. Council gave each agent its own frame of reference and made them deliberate in turns to improve a question or an answer.
It went roughly like this:
- An agent hands over a proposal.
- A panel of members looks at it independently.
- The members discuss it in rounds.
- They vote.
- Council writes a report with a verdict and any dissent.
That's a nice shape for one question with a clear end. It's also a pretty narrow one. Council members persisted and could be convened again, but each session ran toward a verdict. It wasn't a shared room for watching something over time or working through a changing project. If you read the Council code at its last major iteration, a lot of it is machinery for phases, stances, votes, and the final report.
The part Patrick liked was the different frames of reference. The part he didn't need was the courtroom. A design review might need a designer, then an engineering owner, then another round after the code changes. A command center might never need a verdict at all. It just needs someone to notice something and say so.
The switch happened in one commit. The commit that added agent consultations to channels also deleted the Council plugin, so Council is history now. It isn't in the current package. A channel can still pull several agents in on one question, but it can also hold the ordinary work that happens before and after that question.
A public Bot Teams QA capture of sample bots consulting on BB's own interface. It isn't Patrick's Command Center, and it doesn't show that the bots reached a better decision.
A bot is mostly a wrapper
Patrick's first ask was simple. A bot should have its own space on disk, a profile, a mission, memory, and a conversation he can come back to. Originally he pictured each bot getting its own Mattermost account. That idea didn't last long. He dropped it and asked for native BB group chats instead, modeling the bots on Hermes-style profiles.
In Bot Teams, a bot is:
- A model.
MISSION.md, which says what its job is.MEMORY.md, which holds facts and unfinished work between turns.- A workspace for files.
- A conversation you can address again later.
That's what makes a specialist stick around. It's also, as Patrick puts it, mostly a wrapper around a prompt, a model, some files, and memory. One bot on its own isn't that interesting. It gets interesting when you put a few of them in a room.
A public sample profile from the plugin's QA assets. Atlas is an example bot, not one of Patrick's Command Center specialists.
Channels sit on top of threads
This is the part Patrick cares about most.
A channel is the shared conversation. Under it, each bot has a DM backed by its own BB thread. That thread holds the bot's tool calls, approvals, failures, and working history. The channel only holds the messages meant for everyone.
The first time a bot gets a task, it sees a bounded slice of channel history. After that, it gets the new request plus whatever it hasn't seen yet, instead of replaying the whole room every time. When one bot posts an answer, the others pick it up on their next turn.
So a channel doesn't smash several models into one model with a giant shared context window. It gives separate working sessions a place to meet. Each bot keeps its own thread, and Patrick can open that thread when he wants to see what a bot actually did. He can talk to one bot privately, or say something in the room where everyone can answer.
This is also how different models end up in the same conversation. The model is part of a bot's profile, so one channel can hold bots on different models. They're still separate threads with separate models. They just share a room.
Keeping the room quiet
Put enough bots in a room and every message becomes an expensive chorus. Bot Teams has a few small controls for that:
@mentions to bring in a specific bot.@allfor when you really do want everyone.- Chat modes for directed or automatic routing.
[PASS], which a bot can return when it checked its area and has nothing to add. The channel leaves those out of the transcript.
None of these are big features. Without them, though, a room full of bots would get tiring fast.
Making it feel like BB
Patrick also kept pushing on the UI until it felt like the rest of BB. Setting up bots lives in Bot Teams. Conversations live in Channels. A channel is always open, but you can stop any one bot's response. The composer got the same attachments and dictation he already uses in normal BB threads. He also asked for CLI and agent access, not just a UI, so agents can use channels too.
The goal was a room for normal agent work, not another dashboard to babysit every time he has a question.
Command Center
Command Center was Patrick's first channel, and he's using it now. It has specialists for different areas, including systems, social, memes, and weather. They post updates to the channel. There's also a Chief of Staff bot that organizes the others, and that's the one Patrick talks to when he wants the group coordinated.
Channel automations are what give it a rhythm. An automation hands a bot a recurring task, and the answer lands back in the same room. Each run reads the current channel context along with the bot's standing mission.
A public automation test capture. The tasks and replies are QA examples, not Patrick's actual updates.
Patrick hasn't nailed down a strong use case for Command Center yet.
Some of it he likes. Having notifications in one place is nice. And there's something reassuring about knowing agents are checking places like Slack and Twitter on a schedule, even when he isn't looking.
There is also a fair amount of noise. An email bot can summarize messages he gets, but he already gets those messages. A summary of his inbox, delivered next to his inbox, isn't telling him much. A news bot kept sending national news he didn't want until he told it to stop. So he's been adjusting what each bot is assigned to, based on what they actually send back.
A schedule makes a bot check. It doesn't make it a good editor.
Goodbye, Spool
Command Center also made Spool obsolete, at least for Patrick.
Spool tried to build a big local cache of his context and events ahead of time, before any agent needed them. In Command Center, each bot has an area to watch. When a task calls for it, the bot fetches straight from that area's underlying system and reports back. For Patrick, fetching directly turned out to be simpler than reading from a broad cache.
That simplified the plumbing. Getting the data is easier now, and he has a nicer place to read the updates and more control over what each bot watches. Deciding which updates deserve his attention is still the hard part.
A project room with more than one model
The second use is still an idea, not a result.
Picture a project owned by an Astra agent, with Claude sitting in as the designer. Claude doesn't run the project. Patrick asks it for design input when that would help, the owner sees the input in the channel, and work keeps going. Luna Max remains his usual day-to-day model.
This is the original itch from the top of the article, and it's where the difference from Council shows up. Council could collect opinions and hand back a report. A channel can hold the project itself. The designer comments on a screen, the owner changes it, and the designer takes another look.
Whether that actually works depends on things the code can't answer:
- Do the agents actually use each other's work?
- Does routing bring in the right specialist at the right time?
- Can Patrick still follow what happened?
The public code shows how Bot Teams lets bots talk to each other. It doesn't show that this project setup gets better results. There's nothing to report there yet.
Where this leaves things
Patrick started with a council that asked several agents to judge one thing and then stopped. What he has now is a room that keeps separate agent threads together while the work changes. Command Center uses that room to keep an eye on things, though the reports still need a lot of tuning. Project channels might use it to mix models that are good at different things.
The bot profiles are useful. The interesting question is what happens when bots share work, and whether what they send back is worth reading.