Tamux: The Terminal Where the Agent Is the Daemon
A Rust-based runtime for long-running AI work, with persistent state, self-healing loops, and multi-agent governance built into the core.
Tamux is not a CLI tool. It's a full autonomous agent platform. The mental model gap is huge - most people see "terminal multiplexer with AI" but the architecture underneath is a persistent, multi-agent, self-healing, auditable, learning agent platform.
- Tamux moves autonomy out of the prompt and into a persistent daemon, so sessions, memory, and execution survive UI disconnects.
- Its agent loop is built to recover from provider failures, broken tool-call chains, and long contexts instead of treating those as edge cases.
- Planning is gated by confidence, which makes human approval part of the runtime rather than a bolt-on safeguard.
- The mythology-themed agents are not branding fluff, because they give the system a usable mental model for work, governance, and repair.
The strange thing about Tamux is not that it runs agents in a terminal. It is that it treats the daemon as the real product. The UI is temporary. The runtime is durable. That changes everything about how the system handles memory, retries, approvals, and recovery.
The Agent Is Not the UI
Tamux is built around a persistent tamux-daemon that owns the state. Sessions, task queues, memory, telemetry, and agent runs continue even when the terminal closes. In practice, that means the agent behaves less like a chat session and more like a process that can keep working in the background.
Why a Daemon-First Runtime Changes Everything
This is the architectural bet that makes Tamux unusual. Instead of wrapping an existing agent in a shell session, it makes the agent runtime itself the source of truth. If the operator disconnects, the work does not vanish. If the UI is interrupted, the daemon still knows what was running and what comes next.
The Heartbeat: Self-Healing Agent Loops
The core loop lives in the daemon and is designed to survive failure. When a provider times out or a stream breaks, the runner does not just stop. It retries with policy, checks provider health, and can fall back without losing the thread of work.
// Simplified from the agent loop
let runner = SendMessageRunner::new(ctx, retry_strategy);
let request = prepare_request(thread_state)?;
match runner.send(request).await {
Ok(stream) => stream.consume().await?,
Err(err) if circuit_breaker.is_open(&provider) => {
let alt = provider_registry.choose_alternative();
runner.retry_with(alt).await?;
}
Err(err) => return Err(err.into()),
}Two details matter here. First, context can be compacted before a request goes out, which keeps long threads manageable instead of brittle. Second, broken tool-call sequences can be repaired so the next turn starts from a valid state, not from a corrupted transcript.
| Mode | What happens | Result |
|---|---|---|
| Naive agent wrapper | A timeout or malformed stream ends the session. | Work is interrupted and state is easy to lose. |
| Tamux daemon loop | Failures trigger retry, repair, or fallback inside the runtime. | The task can keep moving with the same durable state. |
Planning Before Acting
Tamux does not only execute. It plans a goal run first, then checks confidence before committing to autonomy. If the plan contains low-confidence steps, the system can shift into an awaiting-approval state instead of charging ahead.
tamux keeps the terminal, the agent, and the runtime in one place. Sessions, threads, tasks, approvals, and goal runs live in the daemon, so work can keep moving even when the UI closes.
| Execution style | Decision point | Safety posture |
|---|---|---|
| Fully autonomous run | The agent acts once the goal is clear. | Fast, but riskier when confidence is weak. |
| Gated goal run | Low-confidence steps pause for human approval. | Slower, but safer and easier to audit. |
When Agents Disagree
The collaboration layer makes disagreement a first-class event. Tamux is not pretending every agent agrees. It gives the system a way to debate, vote, and resolve conflicts through governance rather than hiding those tensions behind one prompt.
That matters because autonomous systems fail in messy ways. A worker agent may want to push ahead. A guardian agent may flag the risk. Tamux turns that conflict into a structured decision path instead of a silent override.
| Role | Likely function | System effect |
|---|---|---|
| Swarog | Main orchestrator and worker | Drives planning and execution |
| Weles | Guardian and reviewer | Adds governance and risk checks |
| Radogost | Negotiator | Helps with tradeoffs |
| Domowoj | Local repairer | Stabilizes the environment |
Mythology as Interface
The Slavic names are not decoration. They are an interface for complexity. Once you know which agent is the worker, which one watches, and which one repairs, the system becomes easier to reason about at a glance.
That is a subtle product choice. Good naming reduces cognitive load when the underlying system is busy, stateful, and multi-step. In Tamux, the mythology gives the runtime a memorable map without simplifying the machinery underneath.
How Tamux Compares to Worktree-Based Agent Tools
This is where the design tradeoff becomes obvious. Tools like dmux coordinate external agent CLIs and isolate them in worktrees. Tamux takes a different path. It owns the runtime, the memory, and the recovery loop itself.
| Tool | Core model | State durability | Autonomy | Recovery behavior | Best fit |
|---|---|---|---|---|---|
| Tamux | Daemon-first agent runtime | Persistent in the daemon | Built in | Retry, compaction, repair, governance | Long-running autonomous work |
| dmux | Orchestrates existing CLIs in worktrees | Mostly external | Depends on attached tools | Relies on wrapped tools and panes | Parallel coding workflows |
| tmux-style wrappers | Terminal session management | Session-based | Minimal | Manual or external | Command-line multiplexing |
Why Rust Fits This Problem
Rust is a strong fit because Tamux is really a reliability problem dressed up as an agent product. The runtime has to juggle async IO, multiple providers, persistent state, retries, and observability without turning fragile. Tokio, structured serialization, and Rust’s safety guarantees all support that shape of system.
The language choice does not make the product special by itself. It does make the architecture plausible. A daemon that is expected to survive long sessions, recover from partial failure, and coordinate multiple actors needs exactly this kind of control over concurrency and state.
