You're running two AI agents in parallel on the same codebase. One implements a feature. The other reviews it. A test watcher sits in the corner. Logs stream somewhere. You close your laptop to grab coffee. SSH drops. You open it back up, and half of it is gone.
This is what happens when you try to scale from "one developer, one command, wait for it to finish" to "multiple agents doing different things at once." Your tools assume serial work. Your actual problem is parallel supervision.
The article "Tmux Is The Missing Operating System For AI Coding Agents" maps out why this happens and what actually fixes it. The fix isn't a fancy orchestration platform. It's tmux, a terminal multiplexer that's been doing this job well for fifteen years.
But here's the part that matters: the article doesn't just explain tmux. It shows the specific supervision gaps that emerge when you move from sequential to parallel agent work, and it walks through a concrete workflow that closes those gaps without adding infrastructure you don't need yet.
The Fundamental Shift in Your Job
When you ran code yourself, your job was writing every line. When you run AI agents, your job is different: define tasks, allocate context, supervise parallel work, review results, recover processes that failed while you weren't looking.
That requires a different kind of visibility. Not just "can I see the code" but "can I see what's happening across four simultaneous processes right now, and can I interrupt any of them instantly if something's wrong?"
Terminal tabs give you visibility. They don't give you persistence or clear boundaries. The moment your SSH connection drops, everything you were watching disappears.
Why Parallel Work Breaks Terminal Tabs
One developer. One command. Wait for it to finish. Move on. That's the model terminal tabs were built for.
Parallel agent work breaks it in three specific ways:
Agents work at the same time instead of sequentially. An implementation agent, a review agent, a test watcher, a dev server, all alive at once, not one after another.
Processes run long. They need to stay visible for as long as they're generating output. Not for two seconds. For hours.
Everything needs continuous visibility. Logs, test output, diffs, error traces. Not buried in scrollback you lost twenty minutes ago.
Terminal tabs organize what you can see right now. They don't organize what keeps running after you look away.
Three Concepts, Nothing More
tmux has three concepts:
A session is a persistent workspace. It keeps running whether you're looking at it or not. Close the terminal window, lose the SSH connection, switch machines entirely. The session stays alive.
A window is a tab inside that session, usually one project or one task.
A pane is a single split inside a window, running one process.
You detach from a session and it keeps going in the background. You reattach later and get the exact terminal state back, scrollback included.
tmux new-session -s ai-workspace
tmux split-window -h # split vertically
tmux split-window -v # split horizontally
tmux detach # leave the session running
tmux attach -t ai-workspace # come back to exactly where you left off
That's most of what you need. The persistence is the actual feature.
What Parallel Supervision Actually Requires
You need to see four things at once: what one agent is doing, what another agent thinks about it, whether the tests pass, and what's happening at runtime.
That's four panes with defined jobs:
Pane 1: primary agent implementing one scoped change.
Pane 2: independent review agent spotting regressions, not writing code itself.
Pane 3: test watcher running continuously.
Pane 4: server and runtime logs, so you see the effect of changes as they land.
Your job becomes narrower than either agent's. Approve decisions. Resolve disagreements between what the two agents report. Decide what gets merged. Read the diff yourself before accepting anything.
Without this separation, more agents just means more noise.
The Isolation Problem tmux Doesn't Solve
tmux solves where processes run. It does nothing about two agents editing the same files on the same branch at the same time. That's a bigger source of chaos than any terminal layout.
The answer is git worktrees:
git worktree add ../project-api -b feature/api
git worktree add ../project-review -b review/api
One tmux window per worktree. Each agent has its own filesystem view. Zero risk of stepping on another agent's uncommitted changes.
tmux isolates processes and views. Git worktrees isolate code. You want both. They solve different problems.
This matters more than it sounds. The most common failure mode in parallel agent work isn't terminal layout. It's two write-enabled agents in one worktree, creating conflicting edits that take longer to untangle than either agent saved you.
Script the Layout, Don't Rebuild It
Rebuilding a six-pane setup by hand every morning gets old around day three.
#!/usr/bin/env bash
tmux new-session -d -s ai-project -n agents
tmux split-window -h -t ai-project:agents
tmux new-window -t ai-project -n tests
tmux new-window -t ai-project -n server
tmux attach -t ai-project
Save it, commit it next to your project. The layout becomes something you version instead of something you reconstruct from memory.
A minimal config worth adding on top:
set -g mouse on
set -g history-limit 50000
set -g status-left "#[bold]#S "
bind h select-pane -L
bind l select-pane -R
bind j select-pane -D
bind k select-pane -U
The scrollback bump matters. Agent output and error traces from twenty minutes ago disappear fast at the default limit. Re-asking an agent something it already told you wastes both your time and its context window.
Persistence: The One Thing That Actually Matters
Closing the terminal window. SSH dropping mid-task. Wi-Fi cutting out. Switching machines. A 40-minute agent run you don't want to babysit.
Without tmux, any of these kill your work. With it:
tmux detach
tmux list-sessions
tmux attach -t ai-workspace
The interface disappears. The work doesn't.
One caveat: this is process-level persistence, not machine-level. Reboot the host and the session goes with it. If work has to survive a full restart, you need something on top, a supervisor process or a restoration script.
What tmux Explicitly Doesn't Cover
tmux is a control layer with visibility, interrupt capability, and clear boundaries between concurrent tasks. It has no concept of tasks, dependencies, permissions, or success criteria. It doesn't know what an agent is.
The judgment about what should run, in what order, who's allowed to touch what, that's still you.
And critically: an agent with filesystem write access inside a tmux pane has exactly the access it would have outside one. tmux is not a security boundary. Treat it as one and you'll find out the hard way. Pair it with real isolation: tmux plus git worktrees plus containers plus scoped agent permissions. Each layer does the one thing it's actually good at.
When to Skip This Approach
A single short-lived agent task doesn't need a persistent multi-pane workspace.
Work that has to survive a full machine reboot needs something tmux doesn't give you. Multi-user orchestration or agents spread across several machines calls for real infrastructure: CI pipelines, Kubernetes jobs, a dedicated agent-ops tool.
Anywhere you need actual security or resource isolation, tmux is the wrong layer. That's what containers exist for.
Start Here
One session. Four panes. An agent, a server, your tests, your logs. Detach, walk away, come back to a workspace exactly where you left it.
Plain terminal tabs feel surprisingly fragile after that.
Top comments (0)