My agent orchestrator is 619 commits old, written over about two months. It's a Rust binary that drives a fleet of AI coding agents, each running in a tmux pane. Two choices in that sentence get questioned the most: why Rust, and why tmux. Neither is fashion. Both fall out of one constraint: the system has to run a fleet of agents unattended without me as the runtime.
This isn't a Rust evangelism post. I'm an intermediate Rust user and I won't defend the borrow checker to anyone who doesn't enjoy it. But for this specific shape of program (a long-lived orchestrator that drives other processes), Rust and tmux are the boring correct answers, and I want to explain why.
Rust: the compiler is the agent's runtime
The obvious reason to reach for Rust is distribution. The orchestrator is a single binary with no runtime dependencies: copy it to /usr/local/bin and it runs. No virtualenv, no Node version manager, no "works on my machine." On a fresh laptop the whole control plane installs in seconds. That alone would justify it.
But the load-bearing reason is one I underweighted before I lived with it: the compiler shortens the agent's iteration loop.
I write most of this system with a fleet of Claude agents. When an agent edits a dynamically typed codebase, the loop is: agent edits, I run the thing, it blows up on a typo or a wrong-shape value, I paste the traceback back, the agent fixes it, repeat. I am the runtime. Three rounds, and every round costs a context switch.
When an agent edits Rust, the loop is: agent edits, cargo check runs, the compiler catches the typo or the wrong-shape struct, the agent reads the error and fixes it. Only then does anything actually run. The agent doesn't need me to discover the error class. It has the compiler.
This matters more for agent-driven work than for human-driven work. A human holds a small program in their head. An agent reasoning about a large orchestrator it has only partial context on benefits enormously from a type system that says "no, that field is Option<String>, not String." Every iteration that resolves against the compiler instead of against me saves a round-trip: two minutes of attention plus the cost of breaking focus. Across twenty dispatches a day, that's the line between agent-as-coworker and agent-as-burden. It's the single biggest reason the orchestrator is Rust.
tmux: agents are processes, not requests
The other choice people raise an eyebrow at is tmux. Why drive AI agents through a terminal multiplexer from the 2000s instead of an API and a job queue?
Because an agent in this system is a long-running process, not a request. A single agent might work for forty minutes: reading files, running tests, opening a pull request. The fleet runs overnight. That work has to survive my laptop going to sleep, my SSH session dropping, and the orchestrator itself restarting. tmux is the substrate that gives me exactly that:
Durability. Each agent runs in a named, detached tmux session. It keeps running whether or not I'm attached, whether or not my terminal is open. I start a run and walk away.
Inspectability. Any agent is one tmux attach away from being watched live. When something looks wrong at 2 a.m., I attach to that exact pane and see what the agent sees: no log shipping, no dashboard, no reconstruction. The process and its window are the same thing.
Scriptability. The orchestrator spawns panes, sends keystrokes, and captures output entirely through tmux commands. No daemon to write, no IPC protocol to design. The multiplexer is the process manager, and it's already battle-tested.
tmux turns "run a fleet of agents" into "manage a set of named, durable, inspectable terminal sessions," which is a problem with a thirty-year-old, rock-solid solution.
Where the seams are
The honest part. Reading agent health by parsing pane output is the weakest joint in the design. The supervisor decides an agent is stalled when its pane stops changing; that's pattern-matching on a side effect, not reading a real status signal, and it's fragile. The fix I'm moving toward is structured status files the agents write to directly, with tmux still owning the process and the window. The substrate is right; the health check on top of it was the first thing I rebuilt.
There's also a deliberate split. The orchestrator is Rust because it's a long-lived binary that agents constantly modify: exactly where the compiler earns its keep. The agents it drives are Claude Code, talking to the model through their own well-trodden tooling. Rust runs the control plane; it doesn't try to reimplement the model client. Picking the right language per layer beats picking one language for everything.
619 commits in, the two choices have held. The Rust binary is the part agents can safely rebuild without breaking distribution, and tmux is the part that lets a fleet run all night and still be there, inspectable, in the morning.
I build agent infrastructure — a Rust multi-agent OS I operate daily, and context-vault, a published MCP memory layer that works across Claude Code, Cursor, and Windsurf.
Available Q3 2026. If you're building agent systems and want someone who has shipped this kind of infrastructure, let's talk.