esc
Being riclib

Give Them Their Own Computer

Every week I see a new tool on X that puts a UI around multi-agent coordination. Worktree managers. Branch orchestrators. Agent spawners with dynamic allocation. Merge conflict dashboards. Each one...

April 4, 2026

Every week I see a new tool on X that puts a UI around multi-agent coordination. Worktree managers. Branch orchestrators. Agent spawners with dynamic allocation. Merge conflict dashboards. Each one adds a layer of tooling on top of a problem that shouldn’t exist.

The problem: multiple AI agents editing the same codebase step on each other. They create merge conflicts. They corrupt lock files. They overwrite each other’s work.

The industry’s response: better conflict management. Smarter branching. Worktree automation. Orchestration frameworks that schedule which agent touches which file at which time.

My response: give them their own computer.

The Scaffold Problem

There’s a pattern in software engineering that I’ve watched repeat for twenty years. A problem appears. The industry builds a management layer around it. The management layer is complex, so someone builds a management layer around the management layer. Eventually you have five layers of tooling and the original problem is still there, just buried under abstractions.

Branches are a management layer around the problem of concurrent editing. Worktrees are a management layer around the problem of switching branches. Worktree managers for AI agents are a management layer around the problem of coordinating worktrees. Each layer is correct. Each solves a real problem. And each exists because nobody asked whether the problem underneath needs to exist at all.

Git worktrees share a single .git directory. This means they share lock files. Concurrent operations — the exact thing you want multiple agents to do — occasionally produce errors. The errors are recoverable. The recovery is annoying. So someone builds a lock manager. The lock manager needs configuration. The configuration needs a UI. The UI needs a state store. And now you have four new systems to manage the consequence of a decision you made in the first thirty seconds: sharing a .git directory.

The alternative: don’t share.

The Recipe

My setup took about ten minutes. Claude did most of it. Here’s the whole thing.

Step 1: The Gold VM

Create one OrbStack VM. Install your tools — Go, Node, whatever your stack needs. Clone your repos. Add test data. Configure your editor, your shell, your dotfiles. This is your template.

orb create ubuntu gold

One VM. Everything working. This is the only part that takes thought.

Step 2: Clone

orb clone gold alpha
orb clone gold beta
orb clone gold delta
orb clone gold gamma

Four identical machines in under a minute. Each with its own filesystem, its own git, its own .git directory, its own lock files. No shared state. No contention. No worktree weirdness.

Step 3: The t Script

One shell script. One command. Full workspace.

#!/usr/bin/env bash
set -euo pipefail
SESSION="$1"
DIR="$HOME/src/$SESSION"

if tmux has-session -t "$SESSION" 2>/dev/null; then
  exec tmux attach -t "$SESSION"
fi

COLS=$(tput cols)
LINES=$(tput lines)

tmux new-session -d -s "$SESSION" -c "$DIR" -x "$COLS" -y "$LINES"
LEFT_TOP=$(tmux display-message -t "$SESSION" -p '#{pane_id}')

# Lazygit on the right (50 cols)
RIGHT=$(tmux split-window -h -t "$LEFT_TOP" -c "$DIR" -l 50 -P -F '#{pane_id}')
tmux send-keys -t "$RIGHT" 'lazygit' Enter

# Terminal at the bottom (12 lines)
tmux split-window -v -t "$LEFT_TOP" -c "$DIR" -l 12

# Claude Code in the main pane
tmux send-keys -t "$LEFT_TOP" 'claude' Enter

tmux select-pane -t "$LEFT_TOP"
exec tmux attach -t "$SESSION"

Type t solid and you get: Claude Code top-left, terminal bottom-left, lazygit on the right. The commit river is always visible. The branch is always master. Because there’s only one branch.

Step 4: Color-Coded tmux

Each VM gets its own tmux status bar color. You always know where you are at a glance.

VM Color Status bar
MAC (host) Dark blue 🏡 MAC 🏡
ALPHA Orange ALPHA
BETA Cyan BETA
DELTA Purple DELTA
GAMMA Green GAMMA

This is four lines in each VM’s .tmux.conf:

set -g status-style "bg=colour208,fg=colour232"
set -g status-left "#[bold] ALPHA #[default] "

No dashboard. No agent status page. The tmux bar is the status indicator.

Step 5: cmux

cmux is the cockpit. The sidebar shows every agent — name, state, color bar matching the tmux color. Click to switch. You see the entire factory floor without turning your head.

The key feature: cmux’s built-in browser knows how to talk to each VM directly via SSH. When an agent is running a dev server, the browser connects to it through the VM’s network. No port forwarding. No tunnel configuration. It just works.

Step 6: Tailscale + Mosh + iPhone

Every VM is on Tailscale. They’re reachable from anywhere — not just the local machine.

On the iPhone, I use Moshy. Moshy has built-in tmux support, so it shows me which sessions are running across all VMs. Each VM has Mosh hooks configured — when Claude needs my attention (an approval prompt, a question, a failed test), my phone buzzes. Tapping the notification takes me straight to that agent’s terminal.

I’ve approved architecture decisions from the butcher. I’ve reviewed diffs from the garden. The factory has no walls.

I’ve also tried Claude Code’s built-in remote feature on the iPhone app. It’s promising but still hit-and-miss. Moshy works today, reliably, every time. That’s the whole philosophy: use what works now, composed from existing tools.

Step 7: The Behavioral Principle

This is the part that matters more than any tool.

My agents push every commit or two. They don’t go off for a week and come back with a thousand-line diff. They push early, push often, and fix their own messes. When a push fails because another agent changed something, they pull, read the diff, understand the intent, adjust, and push again. Four seconds.

If you let an agent accumulate work for days before pushing, of course you’ll have problems. Of course you’ll need branch management. Of course you’ll need a merge conflict dashboard. You’ve recreated the exact problem that branches were designed to solve — long-lived divergent work — and then you’re surprised when you need the tooling that goes with it.

The solution isn’t better conflict management. It’s shorter feedback loops. Push early. Push often. Fix your own messes. The branch was never the solution. The branch was the admission that the feedback loop was too long.

What I Didn’t Build

I thought about orchestration. Dynamic agent allocation. Fire up an agent, assign it a task, tear it down when it’s done. A proper framework with a task queue and a scheduler and a state machine.

Then I thought about what I actually needed: four terminals with Claude Code, each on its own machine, each pushing to the same repo.

The gap between “what I imagined building” and “what I actually needed” is the entire orchestration framework industry.

Here’s what I didn’t build:

  • No agent spawner. I run t solid in a tmux pane.
  • No task scheduler. I type the task into Claude Code.
  • No state machine. The git log is the state.
  • No merge conflict dashboard. There are no merge conflicts.
  • No worktree manager. There are no worktrees.
  • No branch strategy. There are no branches.
  • No YAML. At all.

Every component is an existing tool. OrbStack. tmux. cmux. Mosh. Tailscale. lazygit. Claude Code. I didn’t write a single line of orchestration code. The setup is a gold VM, four clones, a shell script, and some tmux colors.

The Rube Goldberg Test

Next time you see a multi-agent coordination tool, ask yourself: what problem is it solving?

If the answer is “agents step on each other’s files” — give them their own computer.

If the answer is “merge conflicts from concurrent work” — push every commit, not every week.

If the answer is “knowing which agent is doing what” — that’s a tmux status bar, not a dashboard.

If the answer is “managing branches across multiple agents” — stop having branches.

The test of a tool is not whether it solves a problem. It’s whether the problem should exist. A lock manager for shared worktrees is a correct solution to an unnecessary problem. An orchestration framework for agent coordination is an elaborate answer to a question nobody needed to ask.

The simplest multi-agent architecture is four VMs, one branch, and git push.

Everything else is a Rube Goldberg machine.

There’s an encyclopedia where software principles get the roast they deserve — Gall’s Law in a boardroom, YAGNI at a buffet, Zawinski’s Law at a nightclub. And a mythology where these ideas have been arguing with each other for a hundred episodes.

See also: