MAS Over Unix Primitives: Why SSH + tmux Is the Only Multi-Agent Framework You Need

The Problem Nobody Is Framing Correctly

The AI industry spends enormous energy on multi-agent orchestration. LangGraph, CrewAI, AutoGen, MetaGPT, n8n — every month brings a new framework. They all share the same premise: you need to build an orchestration layer on top of agents to make them communicate.

That premise is wrong.

The orchestration layer already exists. It's called Unix. It's 50 years old, and it doesn't need an npm update.

---

The Architecture

Here's my setup. A Qwen 27B model running locally on an RTX 3090, and Claude Code (Sonnet/Opus) running on a remote VPS at 4€/month. Both connected through a WireGuard tunnel.

Qwen Code (local, 27B, RTX 3090)          Claude Code (VPS, Sonnet/Opus)
    │                                              │
    │―― ssh dax@10.0.0.1 ――――――――――――――――――――▸│
    │―― tmux send-keys "prompt" ―――――――――――――――▸│  thinking...
    │                                              │  executing tools...
    │◂― tmux capture-pane ――――――――――――――――――│  result
    │                                              │
    │―― tmux send-keys "y" ――――――――――――――――――▸│  confirmation

No SDK. No message format. No JSON serialization. One agent types text into another agent's terminal and reads what appears. Exactly like a human would.

---

What Frameworks Do vs. What Unix Already Does

Inter-agent communication

State persistence

Execution environment

agent = Agent(
    model="claude-sonnet",
    tools=[ReadFileTool(), BashTool()],  # castrated
    max_tokens=4096,                      # limited
)
response = agent.run("analyze this code")  # one-shot stateless

ssh host "tmux send-keys -t claude 'Full mission here' Enter"

Model routing

---

The Test

Here's what actually happened. My local Qwen 27B agent received the instruction to delegate a complex question to a frontier agent. Autonomously, it:

1. Closed the existing tmux session on the VPS
2. Opened a new session with Claude Code
3. Sent /model and navigated the interactive TUI menu
4. Selected Opus 4.6
5. Asked a complex technical question (Transformer vs State Space Model architectures)
6. Waited for the response, captured the tmux buffer
7. Parsed and summarized the result

The "communication protocol" between the two agents: a 200-line markdown file describing which tmux commands to use. That's it. No code, no framework, no dependency.

---

Why Nobody Does This

Two converging biases:

The abstraction bias. The tech industry is addicted to layers. Every problem must have its framework, its ecosystem, its package manager. Nobody asks "is this already solved underneath?". SSH solved inter-machine communication in 1995. tmux solved session persistence in 2007. But because these tools don't have a modern logo and a landing page, nobody considers them a solution to the multi-agent problem.

The naming bias. Claude Code, Qwen Code, Gemini CLI — the word "Code" in the name filters out non-developers and frames these tools as programming assistants. In reality, they are full autonomous agents with filesystem, shell, web access, and self-correction. The interactive terminal is their native interface, not a limitation. When another agent drives them through that terminal, it accesses 100% of their capabilities — not a version castrated by an SDK.

The direction bias. People think "how do I add a layer on top?". The correct question is "how do I use what exists underneath?". Unix primitives have been battle-tested for decades. They won't pivot their business model, change their ToS, or rate-limit you.

---

Emergent Properties

This pattern has properties no framework can reproduce:

Complete environment. Each agent has root access on its machine. Not an LLM behind an API — an agent with a real operating system. Claude Code on my VPS can install packages, read logs, modify configs, browse the web. Everything a human would do.

Dynamic escalation. The local agent decides its own compute level. Simple question? It answers itself. Complex problem? It SSHs to the VPS and delegates to Sonnet. Really complex? It switches to Opus via /model. Routing is an agent decision, not a static configuration.

Total observability. At any point, a human can tmux attach and watch exactly what the frontier agent is doing. No logs to parse, no traces to reconstruct — the terminal is the debug interface.

Anti-fragility. Every layer is an open standard. If Qwen Code disappears, any terminal agent replaces it. If WireGuard has a bug, OpenVPN takes over. SSH won't change its format. tmux won't need a v2 migration.

Zero marginal cost. The infrastructure is a VPS at 4€/month for the VPN relay. Local inference is free (electricity cost). The "framework" is a markdown file. The communication bus is SSH, included in every Linux distribution since forever.

---

The Full Setup

For those who want to reproduce this:

Hardware: any GPU capable of running a 7B+ model (RTX 3060 12GB minimum, ideally 3090 24GB).

Infra: a minimal VPS (cheapest available, WireGuard consumes nothing) for the VPN relay if you're behind CGNAT.

Local agent: Qwen Code + llama-server (or any terminal agent + local inference server combo).

Frontier agent: Claude Code on the VPS, connected with your Anthropic account.

Network: WireGuard between the VPS and your LAN. That's the inter-agent communication bus.

The "framework": a SKILL.md file explaining to the local agent how to drive the remote agent via tmux send-keys and tmux capture-pane.

Mobile access: Termux on Android + WireGuard tunnel. Two aliases: one for the local agent, one for the frontier agent.

Total: ~4€/month + electricity + one Sunday of setup.

---

The Thesis

The best multi-agent systems aren't the ones with the most abstraction layers. They're the ones with the right foundations.

SSH, tmux, WireGuard, bash — these primitives have been battle-tested for decades by millions of engineers. They won't crash in production because an npm dependency changed versions. They won't lock you into an ecosystem. They won't charge you per API call.

The industry is searching for the next MAS framework. The answer has existed for 30 years. You just had to see it.

Frameworks ask: "How do we make LLMs communicate with each other?"

The right question is: "How do we give an LLM the same capabilities as a human?"

The answer is a terminal. It always has been.