Why I'm catching feelings for bb
On August 20, I posted, “I'm catching feelings for @get_bb_app.”
I use it as my cockpit at MPIV. It's just me, working across software projects, writing, research, and the infrastructure that runs it all. I have agents working with me, and I need to see what they're doing, give them direction, and review what comes back.
bb gives that work a home. It's an open-source application that organizes agent work into projects and threads, with connections to the machines where the work runs. I work with several engines through bb, including Codex and Claude Code. Hermes is my persistent agent, with its own tools and skills, and can call on coding engines when a task needs them.
I've also come to appreciate how much I can change the cockpit itself. If I want a different way to review a document or follow a job, I can work with an agent to build an extension. I get to shape the software I'm spending my day in.
Keeping track of the work
I work across several projects, 23 as of this writing, and a project can have more than one conversation going. One thread might handle implementation in an isolated worktree while another holds a review or a piece of research. I want to be able to come back to the right conversation and see what's happening.
bb keeps those threads attached to their projects and working directories. I can choose the engine best suited for the job and follow its progress from the same application. When separate pieces of work would benefit from separate agents, I can split them out and bring the results back for review.
That also gives me somewhere to intervene. I can ask a question while work is underway, correct an assumption, or change the direction. The engine still has to do the work and verify it. I want the files it changed and the checks it ran available when I review the result.
I can use Codex for one task and Claude Code for another while keeping the way I organize and review the work familiar. Those choices can change as the tools develop. I like having a cockpit that accommodates them.
Reviewing what the agents make
A lot of my interaction with agents is reviewing what they've produced. I want to see a running page when I'm making a design decision. For writing and research, I want the document open where I can respond to a particular passage.
I use Noted inside bb for that. Noted is a bb extension I built to review and annotate HTML and Markdown in the thread's side panel. You can attach targeted feedback, route it to agents, and track revisions. Noted is built on Kun Chen's excellent Lavish.
I used Noted to work on this article. I selected the paragraph about Hermes and asked for mpiv-memory to be included. I also corrected the description of the engines and pointed out that the article kept saying “we” when it's just me at MPIV. Those comments went back to the agent with the passages they referred to.
That is the kind of interaction I want throughout my work. I can put the material in front of me and respond to what I see in granular detail. The conversation has something specific to work against, and I can inspect the revision in the same place.
Making the cockpit fit
The enthusiasm I've been reading from other bb users often comes back to customization. Someone gets annoyed by a part of their day and builds a way to handle it inside bb. One user built automatic app previews to make testing across worktrees easier. Another added computer-use controls across agent runtimes.
The agents can help operate bb as well. Its command-line interface lets them inspect projects and threads and coordinate work. I can give an agent responsibility for a bounded task and have it use the workspace to carry that task through, with the results coming back where I can review them.
For me, that makes customization part of the working process. I can notice something I want to improve, describe it while the context is still in front of me, and work on the change with an agent.
The machines behind the cockpit
My setup spans a hub, my MacBook, and an Omarchy Linux machine. bb brings them into the same workspace, and I choose where a task runs based on the project and the tools it needs.
| Machine | How I use it |
|---|---|
| Hub | My central machine for agent work and services that need to remain available independently of my laptop. |
| MacBook | My everyday working machine, including work that needs macOS and its native apps. |
| Omarchy | My Linux machine for agent experiments and compatibility work. |
The cockpit can be open on my laptop while the work runs on another machine. A project still has a particular home, with files and tools available there. Having the machines connected through bb gives me one place to follow that work.
Where Hermes fits
I also run Hermes Agent through bb. I think of Hermes as my persistent agent. It provides its own tools and reusable skills for the responsibilities I give it, and can call on coding engines for engineering tasks. A skill gives it instructions and reference material for a particular kind of work.
I'm interested in Hermes for responsibilities that continue over time. I'm still working out which jobs belong there and how I want to review their results. Ordinary coding work can stay with the engine already working on the project.
Shared context through mpiv-memory
mpiv-memory is my shared memory layer across the setup. I want the cockpit and every engine to draw on the same durable context, including Hermes. If I establish a project decision while working with Codex on my laptop, that decision needs to be available when I return through Claude Code or Hermes on the hub.
A single shared layer gives that context a common home. Individual tools can still keep their session histories and working notes. I use mpiv-memory for the facts and decisions that need to survive a change of engine or machine.
Remembering something also means checking whether it is still true. A saved decision can explain why I chose an approach. A note saying a service was running last week still needs a live check before I rely on it today. I want that habit to carry across the whole setup.
Using it, and contributing to it
I've also contributed a little code to bb. In August, my fix for the Pi extension lifecycle was merged into the project. It came from working with another agent integration and finding something that needed attention.
As with other open-source projects, being able to inspect the software I'm using and contribute a fix is part of the appeal of bb. I can work on an issue in the same kind of environment where I encountered it, then submit the change for review.
I've experimented with maintaining my own changes to bb, too. The direction now is to stay on upstream bb and add focused extensions where I have a reason to. I want to keep benefiting from the work happening in the project while I build the pieces specific to how MPIV works.
Where I’m taking this with C3 OS
C3 OS is the vision I’m working toward for a fully featured bb cockpit for my consulting work. I want to open it and see the campaigns I’m developing, the opportunities I’m pursuing, and the client work underway, with enough context to decide what needs my attention.
The setup brings together tools I already use. Composio connects agents to business applications. Twenty holds CRM records for people, companies, and opportunities. Linear tracks tasks and implementation work. mpiv-memory provides the shared context that needs to travel between engines and machines.
A consulting campaign is one example. I want to start with account research, connect it to the relevant records in Twenty, and track the work in Linear. Agents can prepare sourced briefs, help develop campaign material, and propose follow-up tasks. I review the opportunities and decide who to approach. I send the messages.
When someone responds, that history should carry into the next conversation. Before a meeting, I want the relevant research and previous correspondence available in a briefing. I use Kept for my meeting notes. Afterward, an agent can help turn those notes into a client brief, a proposed engagement, and concrete next steps. I can review those documents in Noted and send specific changes back to the agent.
The cockpit would let me follow an opportunity through that process. I’d see its Twenty record, related Linear tasks, working documents, and decisions waiting on me. If I approve an update to another system, I want confirmation from that system that the change happened.
Hermes would handle incoming events and recurring operational responsibilities. Codex, Claude Code, and the other engines would take on engineering work when the engagement calls for software. bb would coordinate the work and bring results back for review. C3 OS would define the responsibilities, permissions, and checks that keep those pieces working together.
I’ve started defining this through workflow specifications and contracts for how the components communicate. The complete cockpit is still the vision. I want to develop it around consulting work I can follow end to end, adding the views and controls that help me run it.
What I want to share next
I want to show this in use: several threads moving, a document going through review in Noted, and an opportunity progressing through the C3 workflow as I build it. Screen recordings would let me show where I intervene and what changes afterward.
As I develop extensions, I want to share the ones that prove useful and contribute fixes back to bb where they belong. I'll use this blog for the details, X for smaller observations, and a screen recording when seeing the work happen would explain it better.
If you're already using bb, I'd like to hear how you've set it up and what you're building with it.