Three AI agents are rewriting your repo simultaneously. One merges a broken refactor, another spams logs into the void, and you’ve lost track of which terminal belongs to whom. You freeze, alt-tab through seven windows, and pray nothing crashes before you regain control. I lived that exact scenario last month. I was running three coding agents on my self-hosted GPU cluster.

Each was tasked with a different feature branch off the same codebase. Agent A blew away agent B’s changes when it force-pushed its refactor. Agent C’s debug output scrolled past so fast I couldn’t tell if it was stuck or making progress. The core problem isn’t the agents themselves; it’s the context-switching chaos around them. Files get overwritten silently, logs vanish into terminal history, and there’s no clean way to isolate one experiment from another.

The web dashboards everyone pushes solve visibility but trade away something critical: direct access to the underlying process state. That’s why I built Kage, a terminal UI that treats multi-agent orchestration as a software engineering problem rather than a product management one. By using tmux for session persistence and git worktrees for filesystem isolation, I get named panes per agent plus replayable outputs across all three—all in tools that already exist on any Unix box.

Managing multiple AI agents is an engineering discipline issue first and foremost. Terminal-native orchestration beats web dashboards for speed because there’s no HTTP roundtrip between you and the process. It beats them for control because every keypress goes straight to the PTY; it beats them for reproducibility because everything lives in plain-text config files checked into your dotfiles repo.

Kage’s approach collapses this complexity into two concrete primitives: a shell script that spawns isolated tmux sessions per agent job, plus disposable git worktrees created per task branch so experiments never bleed into each other.

No Docker daemon needed—just tmux new-session -d with the right flags in a loop. The rest of this article walks through how to replicate that setup yourself: mapping panes to agents by name rather than guesswork, replaying one pane’s output against another’s commit log when things go sideways, and scripting the entire boot sequence so your next multi-agent sprint starts with a single command instead of thirty minutes of manual setup.

The bug I mentioned earlier: Agent B had completed its task correctly, but only after agent A clobbered its working tree. Replaying pane two’s commit history against pane three’s log output exposed exactly where the race condition lived. That kind of forensic clarity doesn’t exist behind a dashboard GUI. It exists at $ tmux attach -t kage:main.

Section 1: Why Terminals Beat Dashboards

Web UIs are conversation museums. They preserve the past, but they rarely let you run it. I’ve spent a decade bouncing between Jira boards, Linear tickets, and Notion pages. Each one captures a slice of the work, yet none of them let me execute. A dashboard shows me 47 tasks across 12 projects, but it can’t spawn a process or resolve a merge conflict. The terminal does that with one keystroke.

The core problem is representation. Dashboards render state as cards on a grid; terminals render state as text in a stream. That stream is your audit trail, your input channel, and your execution surface all at once. When I orchestrate five Claude instances running parallel code reviews, I need to watch their stdout in real time. A web panel gives me a spinner and a progress bar that lies to me.

My tmux pane gives me raw tokens streaming past at 200 lines per second. Fidelity matters more than aesthetics. A GUI’s polling interval is typically 5 seconds; my terminal updates within milliseconds of each write from the agent’s process. I can spot an agent looping on the same error message three times before any dashboard would even refresh its badge count.

Dashboards also abstract away the filesystem. Every AI agent I run writes artifacts somewhere—a patch file, a log, a test result JSON blob. In Kage, those files live in git worktrees I can see and touch directly from the same window where the agents chatter. Git worktrees are the unsung backbone here. Each worktree is a full checkout at /tmp/kage/agent-003, isolated on its own branch with its own HEAD pointer.

I can switch contexts by changing directories instead of clicking through dropdown menus. The terminal respects process boundaries; dashboards blur them into API calls. When an agent fails in tmux, htop shows its CPU spike to 130% because of an infinite loop I caught early with top. On any web dashboard, that same failure becomes “Error, see logs,” which takes three clicks to reach behind an auth wall and two more clicks into Splunk’s query editor.

Latency compounds those clicks. Every HTTP round trip to refresh my view costs roughly 80 milliseconds locally, but most dashboards sit behind TLS plus an SPA bundle load—easily 400 milliseconds per interaction just to see what changed after my last command ran. Terminal multiplexing turns that around completely: keyboard-driven panes flip focus in under ten milliseconds using tmux select-pane -L.

Once you internalize prefix keys like C-b % for splitting horizontally or C-b z for zooming into one agent’s output stream, you never want another pagination control again; those arrows belong in video games, not production tooling. Kage fixes this by writing each prompt-response exchange straight into numbered buffer files inside .kage/sessions/20250607_1532/. Grep finds anything instantly without leaving my cursor position stable during heavy paste storms from eight concurrent subprocesses writing shell escape sequences simultaneously.

When the Terminal Isn’t Enough

That locality breaks the moment you need to see three agents’ work side by side. Tmux panes give you splits, but they’re static frames. Resize one and another shrinks, and your eyes play whack-a-mole across divergent scrollbacks. So I stop pretending tmux is a window manager. Instead, I assign each agent its own session, then use tmux choose-tree to hop between them with a fuzzy finder overlay. The keystroke is two characters: prefix, then s.

From there, arrow keys or type-ahead filter drops me into any agent’s world in under a second.

The real payoff lands when an agent goes silent mid-task. I switch to its session, hit Ctrl-b [ to enter copy mode, and page back through its exact command history—every pip install, every failed test run, every hallucinated file path it tried to create. That buffer is a forensic record no dashboard exports with fidelity. Git worktrees still handle isolation, but sessions handle attention.

Two different problems, two different tools. I’ve stopped trying to watch everything at once. The discipline is knowing which pane deserves focus and trusting the others to keep running. A single status line in my tmux config shows me each session’s name and current branch using #{session_name} and #{pane_current_path}—enough context to decide where to look next without actually looking. That’s the shift from orchestration to delegation. You’re not managing agents; you’re managing your own attention budget across them.

The Latency Tax Nobody Measures

Attention budgets have a physical cost. Every time I tab from terminal to browser to check an agent’s progress, I’m paying a switching penalty that Chrome’s dev tools can’t itemize. My tmux panes stream. That difference matters when three agents are mutating files simultaneously and one of them just clobbered another’s diff.

With Kage, I see the collision in real time because every agent occupies a named pane, and their output flows past my eyes without a refresh button in sight.

The counterargument is fair: for casual chat, ChatGPT’s web UI is fine. You type, it answers, you read. But agents writing code aren’t having a conversation. They’re spawning processes, editing files, running tests that fail in ways their own logs don’t reveal.

And here’s where the dashboard model breaks completely: when something goes wrong, you need the full context of how it went wrong. Git worktrees give me that context as plain text. Each agent operates in its own directory: git worktree add ../kage-agent-42 -b fix/race-condition. When that agent spirals into broken edits, I don’t scrub through screenshots or replay session videos.

I read the commit log with timestamps, check which files changed against which branch point. And then there’s recovery. A web UI loses everything when the tab crashes or the server hiccups mid-session. Tmux writes state to disk. tmux save-buffer preserves scrollback as a file; tmux-resurrect restores pane layouts after reboot. My entire multi-agent orchestra persists as text on disk, replayable like a debugger stepping through execution history.

That reproducibility turns chaos into archaeology rather than panic—not network latency, but cognitive overhead per switch action counts double at forty tabs deep. Dashboard telemetry gets summarized; raw output doesn’t hide edge cases behind pretty graphs. The browser remains right for planning discussions with one model at low stakes. For orchestrating three concurrent code-generating agents racing toward conflicting merge requests, I’ll take unpolished text over smooth pixels every single time, because failure leaves better fingerprints there too.

Closing the Loop on Agent Chaos

Those failure fingerprints are exactly what Kage preserves. When the third agent clobbered a shared config file mid-sprint, I didn’t dig through scrollback or pray to a web dashboard’s log viewer. I replayed pane 2’s output against pane 3’s commit history in under a minute. The fix was mechanical. git worktree add gave each agent its own branch isolation from the start, so the clobbering never touched production code.

A single kage-init.sh script spawns three named tmux sessions with dedicated status bars, plus a fourth window aggregating their combined stderr. That layout is the whole argument made visible. Each pane is a sandbox; each status bar shows only that agent’s pending changes and active branch. No tab-switching, no context loss, no wondering which terminal belongs to which model.

Web dashboards solve visibility with more chrome. Kage solves it with discipline. Tmux sessions cost nothing to spawn, and git worktrees make each experiment disposable in seconds. The reproducibility payoff compounds. That bug we chased—the replay of pane outputs against commit logs produced an exact repro script, not a vague “it broke somewhere” post-mortem.

Ready to stop herding cats? Clone our reference dotfiles, run kage-init.sh, and watch three agents work in perfect isolation within five minutes. Managing AI agents is software engineering precisely because it demands the same rigor as any distributed system: explicit state, isolated execution, reproducible failures. Tmux gives you the sandboxes; git worktrees give you the boundaries; Kage just wires them together without asking for your browser tab count first.

Kage is just a scaffold of shell history and session state, but the principle matters more than the tool. If you can’t see an agent’s raw output stream, replay it, and kill its branch without collateral damage, you’re not orchestrating anything. The real breakthrough was realizing that git worktrees plus tmux give you process isolation for free, no orchestration framework required.

Keep Reading

That combination turns chaos into something inspectable. So here’s my open question: what happens when we stop treating agents as chat windows and start wiring them like build processes? Version control already solved parallel human workflows decades ago. We’re just catching up to our own infrastructure. Start with one repo, three panes, and a single git worktree add command. See how far that gets you before adding anything fancier.