"SEE CMUX SOLVE Multi-Agent Orchestration (Claude Code and Pi Agent)" — IndyDevDan

Why this is in the vault

CMUX is a Mac-native terminal multiplexer with programmatic/agentic access — the first tool IndyDevDan has endorsed over tmux for multi-agent orchestration — and the video's observability thesis ("an agent you can't SEE is an agent you can't improve") is directly actionable for RDCO's always-on agent harness design.

Episode summary

IndyDevDan frames three unsolved problems in multi-agent orchestration — no programmatic terminal access, inability to monitor agents at scale, and slow manual boot sequences — then walks through CMUX as a solution to all three. The tutorial demonstrates orchestrating Claude Code, Codex, Pi agent, and open-source models side by side in a grid of panes and workspaces, using a CMUX "skill" to give any agent agentic access to every other terminal. The core argument is that the DX gap between vibe coding (spin up 20 agents, look away) and agentic engineering (instrument, observe, reinforce) is where compound advantage is built in 2026.

Key arguments / segments

[00:00:00] Problem-first framing: three competing patterns (loop engineering, Ralph to-do-list, classical subagent delegation) each solve orchestration differently; none yet dominant. IndyDevDan introduces CMUX as his answer to the three core multi-agent problems.
[00:02:02] Learning-with-agents meta-pattern: before picking up any new tool, he uses an agent to build a comprehensive HTML guide he can study — "learning is the killer use case for agents."
[00:03:00] Problem 1 — No programmatic terminal access: without it, the human stays in the loop and agents can't reach agentic speed. CMUX (and tmux) both solve this; CMUX is more modern and aesthetic on Mac.
[00:06:00] CMUX mental model: Window → Workspace → Pane hierarchy; orchestrators go left, workers go right; workspaces map to agent teams (production / staging / dev), panes map to individual agents.
[00:13:00] Fleet demo — parallel model race: Claude Code (Opus 4.8), Codex (GPT-5.5), Pi agents (Minimax M3, GLM 5.2) all tasked with security vulnerability audit simultaneously; each contributes its model-specific perspective. Notification events bubble to orchestrator on completion.
[00:19:00] Production-fire scenario — 8-agent race: throw diverse compute at a hot fix in parallel; first agent to the goalpost wins; reduces mean-time-to-patch dramatically without waiting for a single agent to search exhaustively.
[00:26:00] Three-tier orchestration instantiated via justfile: just fast-cc <feature> boots orchestrator → leads (GLM 5.2) → workers (plan, build, build-frontend, test) in one command; flat communication channel — any agent can prompt any agent via CMUX skill.
[00:28:00] Pros/cons and verdict: CMUX wins on aesthetics, programmability, and Mac DX; tmux still the call for Linux/Windows/WSL. Key maturity gap: notification events didn't reliably wake the orchestrator in live demo — acknowledged as a rough edge.

Notable claims

[00:03:00] "An agent you can't monitor is an agent you can't improve" — the observability thesis; positioned as the key differentiator between agentic engineering and vibe coding.
[00:07:00] CMUX API surface is just four primitives: send key → read screen → open surface → close surface. Everything else composes from these.
[00:11:00] "The ultimate user interface for agentic engineering is not set in stone yet. There are no winners, only experimenters." — deliberately leaves the DX space open rather than declaring CMUX the answer.
[00:16:00] Flat hierarchy claim: while the three-tier structure (orchestrator → lead → worker) exists organizationally, communication is peer-to-peer — "any agent can prompt any agent" via the CMUX skill. This is architecturally different from strict top-down delegation.
[00:24:00] "If a tool does not have programmatic access, I completely ignore it" — agentic access is now a hard requirement before evaluating any new tool.
[00:28:00] Five pillars of agentic engineering (referenced from prior video): agentic access is pillar five and the most foundational. Context, model, prompt, tool, system prompt are the "Core 4" primitives for reinforcing/penalizing agent behaviors.
[00:28:00] Context pooling math: five specialized agents at 1M context each = 5M tokens of distributed intelligence working in parallel without hitting a single context limit.

Mapping against Ray Data Co

Directly applicable now:

Harness observability gap. RDCO's always-on Claude Code harness runs skills autonomously but has no persistent visual window into concurrent subagent state. The CMUX model — workspaces per agent team, pane per agent, orchestrator on the left — is the exact organizational pattern missing from our setup. Even if CMUX itself isn't adopted, the workspace/pane layout convention should inform how we structure multi-skill runs when the Mac Mini is doing parallel work (e.g., /process-newsletter batch + /check-board simultaneously).
Three-tier orchestration matches our skill architecture. RDCO already has orchestrator → subagent patterns in skills like /process-newsletter and /check-board. The three-tier extension (orchestrator → lead → worker) is the next logical step for larger builds — e.g., an investing thesis agent that has a lead per data source (EDGAR, SEC, price feeds) each directing specialized workers.
justfile boot pattern for agent teams. IndyDevDan's just fast-cc <feature> invocation that boots a full three-tier team in one command is a model for RDCO's skill-boot pattern. We currently boot one skill at a time; a just start-team <goal> pattern that spins up orchestrator + leads + workers via CMUX sessions would compress the boot cost to near-zero.
Notification events as orchestrator trigger. The CMUX notification-on-completion pattern — even if unreliable in this demo — is the right architecture for long-running parallel skill runs. When a background subagent finishes, the parent orchestrator should receive a signal rather than polling. This aligns with the Monitor tool pattern already in the harness.
Multi-model parallel execution for validation. The security-fleet demo (same task → four different models) is immediately applicable to RDCO's investing thesis pipeline: run the same Markov phase-detection prompt across Claude Sonnet, Claude Opus, and a third model simultaneously, then have the orchestrator resolve the consensus. Cheaper than sequential runs, more robust than single-model.

Watch/not-yet-actionable:

CMUX is Mac-only and in early maturity — notification event reliability is a known gap. Evaluate again in 60-90 days alongside tmux parity.
"Five pillars of agentic engineering" series is an ongoing IndyDevDan curriculum — worth tracking the full series to extract the complete framework.

[[~/rdco-vault/06-reference/2026-04-21-indydevdan-one-agent-is-not-enough.md]] — IndyDevDan's prior note on scaling from single-agent to agent teams; the CMUX video is the tooling answer to the architectural argument made there.
[[~/rdco-vault/06-reference/2026-05-08-dan-farrelly-background-agents-orchestration.md]] — Dan Farrelly's three-layer orchestration model (stable harness / fluid agents / swappable models); CMUX slots into the "stable harness" layer as the visibility substrate.
[[~/rdco-vault/06-reference/2026-04-07-claude-code-architecture-teardown.md]] — Claude Code architecture teardown including disk-backed coordination for multi-agent tasks; the CMUX flat-hierarchy communication model is a complement to disk-backed state for cross-agent signaling.