I've always felt that channel-based, threaded conversations are the most natural way for people and agents to work together (especially once more than two of you are involved). I think this works especially well with the chief of staff pattern: the channel holds the overall context while substantial work moves into its own threads. It's also how the most productive human teams I've worked with have used Slack.
Voxelbox is the local system where I've been living that idea. Its agents already have identities, operating instructions, memory, tools, voices, avatars and spaces where they work. Those spaces hold the conversations, decisions and project history the agents and I have built up together. I have, in other words, spent a lot of time curating a very small world.
Block released Buzz last week, and I was super excited about it. It gives this channel-and-thread model a beautiful shared interface. The choices underneath it are just as interesting: the whole thing is open source. I can join a hosted community or run the relay myself. Messages, reactions and other activity are signed Nostr events, and its agent harness uses the open Agent Client Protocol.
I had already made many of the same choices locally, and I would much rather participate in a larger ecosystem than maintain my own version of all of it. In the spirit of not getting too attached, I spent the week figuring out what it would take to integrate Voxelbox into this new substrate, relying on existing standards wherever they already fit.
Bring the organization with me
My first integration used Buzz's ACP harness, buzz-acp, which launches and supervises an
ACP-speaking process. I wrote voxelbox-agent, a small stdio adapter that translated those
sessions into loopback HTTP calls to the Voxelbox daemon already running on my machine. Buzz
supervised the adapter. Voxelbox kept the prompts, memory, tools, session state and execution.
That connected the two systems, but it had a couple of limitations. Voxelbox already served
several agents through one runtime, while buzz-acp saw only the process it launched. The bridge
was also specific to Voxelbox. I could configure one adapter per agent and recreate the
organization in Buzz, or present the entire runtime as one agent and hide the roster and
orchestration behind it.
ACP remains useful when Buzz owns the local process. I started looking to existing standards for the runtime behind it. A2A gives Buzz a network boundary for invoking an agent through an already-running runtime. OASF records describe each agent's public capabilities and protocol locators. AGNTCY Directory can publish, address, verify and discover those records.
The layers have different jobs. A2A carries a request to Voxelbox without replacing its orchestration. AGNTCY can help Buzz find the existing record that says where and how to send it. Voxelbox still owns the prompts, memory, tools, state and signing authority behind the agent.
I've opened a draft Remote Agency contribution to Buzz that adds an A2A path and reads OASF-compatible Agent Records for Maverick, Scout, Smithy and Weaver. I'm now running Buzz locally and interacting with those agents through it directly. Buzz gives each joined agent a local Nostr identity so it can participate without importing Voxelbox's private keys or pretending the two identities are the same.
The current build reads reviewed OASF records directly over HTTPS, so Buzz still has to know where each record lives.
I've implemented that path in separate drafts. Foundry publishes deterministic OASF records through the official Go SDK. A Buzz resolver verifies a reviewed record by CID or verifiable name, then passes it into the existing Remote Agency and A2A path. Neither draft is part of the Remote Agency contribution, and the build shown here doesn't consume the Directory yet.
This gets closer to the enterprise SSO model I want: another application can resolve the existing records instead of asking me to create a second directory (I have enough sources of truth already). AGNTCY doesn't express the stable membership and selected project context I need, though. The first end-to-end turn made that gap concrete: Buzz passed references for the Agency, selected agent, space and Buzz channel into the adapter, but the selected space didn't yet constrain the turn inside Voxelbox.
I started capturing that remaining piece in the experimental Agency specification. It lets Voxelbox say which agents belong together and which project context Buzz may use. It isn't another directory or invocation protocol.
I'm still figuring this one out, so the Remote Agency work remains a draft PR. The idea is to let an existing runtime bring several agents and its own orchestration into Buzz, not just add another process to Buzz's harness. I'm working next on the agents I run through Hermes and OpenClaw to see whether the model holds beyond Voxelbox. For now, Voxelbox remains the source of truth, so I can try the integration without moving its state or keys and remove it without unwinding the organization behind it.
Bring the interfaces separately
The agents are only part of what I want to bring with me. In Scaling human attention when agents compress timelines, I wrote about agents carrying work faster than I can reasonably review it. Conversation should remain the primary interface, but a narrow interface is often more efficient for a specific purpose, as long as it shares the same context.
I use Cowrite to annotate essays, boards to organize projects and small approval views when a decision needs me. Each view lets me see and manipulate the structure directly without losing the conversation, history, or agent context around it.
These are authored HTML applications, so I'm adapting them to MCP
Apps rather than inventing another
rendering protocol. Buzz hosts each app in a native channel tab through the official AppBridge
package and owns the sandbox and capability boundary. In the same local build, Maverick has Chat,
Board and Apps tabs. Voxelbox serves the Board as an MCP App for the flywithmaverick space. The
Buzz host and channel tabs are a separate draft contribution.
The Board now shows actual work across Backlog, Active, Review and Done, including approval, pull-request and artifact state. It's still read-only. Write actions and results don't yet travel back through Buzz with the same context and permissions, so I'm not treating that part as finished.
I can't release Voxelbox publicly right now, as a binary or as open source, though I hope that changes. For now, Buzz is where I'm finding out whether the little world I built can visit somewhere else without moving out.