terminal multiplexing for agents — or: how I stopped managing terminals and started conducting orchestras

by Ray Svitla

the moment it breaks

you’re running Claude Code in one terminal. Gemini CLI in another. OpenCode reviewing the output. Codex handling tests. maybe a fifth agent doing documentation.

five agents. five terminals. five context windows you’re mentally juggling.

at some point — usually around agent three — you stop orchestrating and start firefighting. which terminal was planning again? did the review finish? where did that artifact go?

the agents aren’t the problem anymore. terminal management is.

enter agent-deck

someone finally built tmux for AI agents.

agent-deck dropped today (1,729 GitHub stars in hours) with one core insight → if you’re running multiple agents, you need infrastructure that assumes multi-agent as the default state.

one terminal. every coding agent. switch between Claude Code, Gemini CLI, Codex, OpenCode without losing context. unified logging. shared artifacts. session replay.

not “manage terminals better.” eliminate terminal management entirely.

the interface caught up to the workflow.

why this matters (or: when the bottleneck shifts)

most agent tooling optimizes single-agent performance. faster context switching. better memory. smarter tool use.

but when you’re running agents in parallel — planning, coding, reviewing, testing — the bottleneck isn’t agent quality. it’s coordination overhead.

which agent said what? which context window has the latest state? did I restart the right session?

agent-deck says → stop managing that manually. here’s infrastructure that assumes you’re conducting an orchestra, not playing a solo instrument.

the multi-agent workflow (or: what actually happens when you use this)

here’s the pattern that emerged after a day with agent-deck:

1. spawn planning agent
Claude Code, thinking mode on, “design a feature for X.”

2. parallel implementation
three agents simultaneously → backend (Gemini), frontend (Codex), tests (OpenCode). each in its own session, all visible in one TUI.

3. review loop
fifth agent (Claude again) reviews all three outputs. flags inconsistencies. everyone iterates.

4. artifact handoff
shared context means no copy-paste. agent 2 reads what agent 1 wrote. agent 3 references agent 2’s output.

the workflow isn’t “agent does task → I check → next task.”
it’s “agents coordinate autonomously while I conduct.”

what changes when this becomes normal

three things shift:

1. you stop being the integration layer

before → you’re manually shuttling context between agents. “hey agent 2, here’s what agent 1 said.”

after → agents share context directly. you conduct, they integrate.

2. parallelization becomes real

before → sequential. finish task 1, start task 2.

after → parallel. spawn 5 agents, let them work, intervene when coordination breaks.

3. the mental model inverts

before → “I use agents as tools.”

after → “I conduct agents as a team.”

the relationship changes. you’re not a user anymore. you’re a conductor.

the infrastructure question (or: why this is bigger than one tool)

agent-deck isn’t just a better terminal multiplexer.

it’s the first serious answer to “what does multi-agent infrastructure actually look like?”

most frameworks assume single-agent. spawn, execute, return. agent-deck assumes swarm. always-on sessions, cross-agent context, orchestration as default.

when the infrastructure assumes multi-agent, the capability ceiling lifts. not because agents got smarter — because the coordination tax dropped.

what breaks (and what doesn’t)

honest assessment after testing:

what works:

• context switching is seamless. no mental overhead.
• shared artifacts eliminate copy-paste hell.
• unified logging means debugging is readable.

what’s still hard:

• agents still drift off-task. no amount of TUI magic fixes that.
• conflict resolution is manual. when two agents disagree, you still decide.
• the learning curve is real. tmux users adapt fast. everyone else needs a day.

this isn’t magic. it’s better plumbing.

the pattern (or: what comes next)

agent-deck is the first wave of agent-native infrastructure.

not “better terminals for humans who use agents.”
but “infrastructure designed for multi-agent as default state.”

what comes next:

• cross-agent memory → agents share knowledge graphs, not just logs.
• emergent coordination → agents negotiate plans without human steering.
• observability dashboards → not “what is each agent doing” but “what is the swarm accomplishing.”

when the infrastructure assumes swarms, the capability ceiling lifts.

the question nobody’s asking (but should be)

here’s the uncomfortable part → most of us are still in single-agent mode.

one Claude session. manual context switching. sequential workflows.

agent-deck (and tools like it) assume you’re already running 5 agents in parallel. most people aren’t.

the capability is there. the infrastructure is there.
are you using it?

or are you still treating agents like better autocomplete?

practical takeaway (or: what to actually do)

if you’re running multiple agents manually → try agent-deck.

if you’re not running multiple agents yet → start. spawn a planning agent, a coding agent, a review agent. watch how fast coordination overhead becomes the bottleneck.

then reach for infrastructure that assumes multi-agent.

the tooling is catching up to the workflow. the workflow assumes parallelization. parallelization assumes orchestration.

the bottleneck shifted. did you notice?

Ray Svitla
stay evolving 🐌