This post is meant to explain how I started orchestrating my agents. I want also to provide some useful tips based on my current setup.

Creating Thurbox

Creating Thurbox was a critical first step. When I started, tools like Orca, Herdr, and the current wave of IDE plugins didn't exist. I initially built it around Claude Code to fix what I felt was missing: a straightforward way to manage roles, MCPs, skills, automations, and multiple persistent sessions via tmux, all wrapped in an accessible TUI with remote-control features. Over time, agents began handling many of these tasks natively. Furthermore, my original setup was overly tailored to Claude Code, the only agent I used at the time. As a flood of new development agents hit the market, building an agent-agnostic solution became mandatory, leading me to strip away unnecessary overhead.

User interaction was another key puzzle. Early on, I shipped Thurbox with a thurbox-mcp binary pre-configured in an "admin" session. This allowed me to create and configure new agent sessions directly from an existing master session—the early groundwork for fleet orchestration. However, I quickly learned that MCP wasn't optimized for speed or token efficiency, prompting me to build thurbox-cli instead.

thurbox-cli fast became the backbone of session orchestration. It enabled AI agents to autonomously spin up their own sessions using Git worktrees. To streamline inter-session communication, I introduced parent sessions (indicated by ↳ in the TUI), which inject a parent reference into child sessions. Agents can now manage sub-sessions independently, sparing the end user from juggling worktrees or manually maintaining clean context windows. To top it off, Thurbox handles symlinks so agents can spin up with custom contexts spanning multiple distinct repos, worktrees, and directories.

I then introduced Thurbox v2 to overhaul the end-user experience. My goal was simple: anyone should be able to say, "Add a custom display to the Thurbox TUI," and make it happen instantly.

The entire UI/UX is now powered by Lua, allowing users to fully customize and control the interface at runtime without touching a compiler. Because the original UI was built almost exclusively around my personal workflow, v2 opens the door for anyone to design their own layouts and tailor features to their exact needs.

Quality goes hand in hand with performance. High performance is critical when orchestrating multiple concurrent agents. While alternative platforms often build custom backend runtimes, I opted to leverage battle-tested tmux, which fully satisfies agent CLI requirements with minimal overhead. The TUI itself is also rigorously performance-tested to ensure fast, responsive feedback under heavy load.

By the way it can run Doom! (Type doom god mod cheat code iddqd in Thurbox website)

Fleet Orchestrator

The natural workflow with Thurbox was to have a primary session break down tasks and launch new ones using thurbox-cli. This approach often beats standard sub-agents because complex work requires iterative, targeted prompting in separate sessions—something sub-agents handle awkwardly while risking context pollution.

While this pattern works well for single repositories, real-world development usually spans multiple repos and contexts. To solve this, I created a central private repository called fleet, filled with markdown documentation detailing the various repos I work on and how they interconnect.

I quickly added scripts to fleet to automate custom session creation and pull real-time context and updates from active Thurbox sessions. This shifted my workflow so that I almost exclusively interact with the main mission-control session, a lifesaver when managing over a dozen distinct projects daily. While similar orchestration tools like firstmate exist and work well, they aren't tailored specifically for Thurbox. That drove me to build and share an open, project-agnostic version of fleet that now anchors my daily work.

Fleet is still young, far from bug-free, and continuously evolving toward stability. However, it is rapidly progressing into a reliable, production-ready solution.

Fleet installs directly as a Thurbox extension. Extensions enable self-healing sessions that automatically recreate themselves if interrupted on TUI start, along with scheduled automations that execute specific binaries or agent tasks on a timer.

The primary control plane revolves around a "📡 Mission Control" session, which acts as the orchestrator dispatching work to individual "🚀 Task" sessions. The architecture relies on two core primitives:

• Registry: Stores global context and maps out repository responsibilities across your projects.
• Queue: Tracks real-time task statuses and lifecycle states.

Under the hood, dedicated scripts handle these systems, which agents trigger on demand. Once installation and onboarding in Mission Control are complete, you can begin delegating tasks seamlessly:

Prompt: Create a new repo for App 1
Initializes the codebase, updates the Registry, and spins up a dedicated task session.

Prompt: Update Repo 2
Contextualizes the target codebase through the Registry and queues a session to execute the changes.

Keeping Quality

Reviewing code manually is virtually impossible at agent speed. To counter this, I rely heavily on automated guardrails, combining strict CI static analysis with a custom publish skill that runs AI-driven quality gates before any code hits production.

This custom publish skill was my first, and it remains one of my most heavily used tools. While I continuously refine it for my own workflow, it is meant to serve as a foundation for you to fork and adapt to your specific pipeline rather than a one-size-fits-all solution.

I also use thurview, a custom skill designed to help me analyze and refine system architecture and design choices for every change.

Some Tips

Token optimization becomes critical when orchestrating across a large set of projects. To keep overhead low, optimize your instruction files and skills:

• Keep the global instruction file minimal: Focus on concise, high-level directives rather than exhaustive rules.
• Automate project instructions: Allow your agents to dynamically update project-level context files as the codebase evolves.
• Modularize with skills: Split heavy procedures into isolated, single-purpose skills to load only what is relevant to the active task, drastically trimming token usage.

Prefer dedicated CLIs over MCP servers. In development environments, MCP often introduces unnecessary protocol overhead and context bloat, leaving only a handful of niche use cases where it truly outperforms a simple binary.

Prefer agent-agnostic patterns over vendor-specific ones. A simple, effective approach is to maintain an AGENTS.md file as your source of truth for repository instructions, then create a CLAUDE.md symlink pointing back to it. This ensures compatibility with Claude Code while keeping your setup cleanly decoupled and ready for any future agent.

When using Thurbox, leverage thurbox-cli freely within your prompt workflows. Instruct your agents to run thurbox-cli commands directly to inspect state, coordinate tasks, and delegate sub-sessions seamlessly across your environment.