One coding agent is a chat. Several coding agents are an operating system problem. You need names, routing, status, logs, handoffs, and a way to stop work that is going in the wrong direction. tmux is a surprisingly good foundation because it makes each agent a visible, durable process.
Give every agent a role and a pane
Start with a small team. A builder edits code, a reviewer reads diffs, a tester runs verification, and an operator coordinates the work. Put each role in a named pane or window. The role name matters because humans route tasks by responsibility, not by process id.
session: product-work
window 1: operator
window 2: builder
window 3: reviewer
window 4: testerKeep roles coarse. If every task creates five bespoke agent types, the coordination cost overwhelms the benefit. A few stable roles develop predictable habits and make failures easier to diagnose.
Status must be external to the chat
Do not rely on scrolling through transcripts to learn who is busy. A tiny status file, socket registry, or dashboard can track whether a pane is idle, busy, blocked, or waiting for review. The status surface should be machine-readable so dispatchers can avoid assigning work to the wrong pane.
{
"builder": {"pane":"%4","state":"busy","task":"checkout fix"},
"reviewer": {"pane":"%5","state":"idle"},
"tester": {"pane":"%6","state":"blocked","reason":"missing seed data"}
}Use briefs, not vibes
Agent tasks should include a goal, files or areas to inspect, hard constraints, acceptance checks, and a reply channel. This is especially important when the operator is on a phone. A good brief gives the agent enough context to finish without repeated round trips.
Keep terminal control boring
For short commands, direct tmux key injection is acceptable. For long briefs, use tmux buffers. For repeated dispatch, put a socket layer in front of tmux. These are not competing ideologies; they are transport levels. Choose the simplest one that gives the current task reliable delivery and observable failure.
Design for interruption
Teams of agents will occasionally do too much. They may run a slow command, modify the wrong layer, or continue after requirements change. Keep process ids visible, avoid hiding work in background jobs, and make stop commands part of the operating model. The goal is not full autonomy. The goal is controlled parallelism.
A terminal agent team works when it feels like a workshop: every bench is visible, every task has a label, and the operator can step in at any time.