NTM (Named Tmux Manager)
Turns tmux into a local control plane for multi-agent software development: session orchestration, work triage, safety approvals, and automation surfaces in one Go binary.
Safety design is unusually strong: policy/approval system, two-person approvals with self-approval rejected, labels as authorization boundaries for auto-assignment, fail-closed behavior, worktree isolation, and comprehensive rollback surfaces (checkpoints, timelines, audit) — full marks for user_confirmation and rollback. Deductions: the product drives coding agents that execute arbitrary shell commands and perform impactful git merges; external_effects relies on the policy layer with no execution-level proof in evidence, so 1; the recommended install is curl | bash executing a remote script, weakening least_privilege and data_flow_transparency; govulncheck is continue-on-error in CI and bubbletea is locally replaced, so dependency_security 2; sensitive_data_handling rests on an assertion that credentials stay out of NTM config, so 2.
README is internally consistent, documents fail-closed behavior, typed robot error documents, ntm deps -v, and graceful degradation; CI includes reality guards and a parity gate. All three criteria merit 2. Not 3 because the core Go source is absent from the provided files, so actual error-handling implementation cannot be statically verified.
Audience and scenarios are exhaustively covered; Grok phase-one explicitly lists unsupported operations and fails closed, earning full marks for capability_boundaries and audience_and_scenarios. Deductions: environment is Linux/macOS only (Windows explicitly excluded), with hard tmux and multiple external-tool dependencies — environment_fit 2; trigger precision relies on readiness regexes and explicit robot surfaces described but not shown in implementation — 2.
Information architecture, command map, and user/project config layering are excellent; known-limitations disclosure is candid (Grok scope, config migration notes) — full marks. Heavy deductions: the license is MIT plus a restrictive rider targeting OpenAI/Anthropic — likely not OSI-compatible and of doubtful enforceability, consistent with NOASSERTION — license 1; install_notes is a single curl | bash line with no manual or checksum-verified path — 1; no CHANGELOG appears in evidence despite VERSION/release preflight in CI — versioning_changelog 1; single-author maintenance (Jeffrey Emanuel) with low bus factor — maintenance_responsibility 2.
Output usability is excellent: robot JSON, OpenAPI with CI drift detection, parity matrix, markdown/terse formats; the problem statement is clear and the combination (tmux multi-agent + policy/approvals + work-graph triage) has genuine marginal value — both full. cost_benefit 2: the system requires tmux, several external CLIs, and Agent Mail; the benefit depends on ecosystem availability and the maintenance surface is large.
README claims are partially corroborated by CI workflows and test scripts (OpenAPI drift gate, coverage threshold, SHA-pinned dependencies, parity harness) — cross_source_corroboration 2; claim_traceability 2: claims are specific (badge state table, one-shot approval consumption) but the main source code is absent from the evidence, so implementation cannot be checked item by item; fact_inference_separation is good — the README explicitly separates claimed from unclaimed capabilities — but the doc is self-assertive without third-party verification, capped at 2.
- Do not blindly run the README's curl | bash install; inspect install.sh and verify checksums first.
- The license is MIT plus a rider barring OpenAI/Anthropic and affiliates; it is not a standard OSI license and requires legal review before enterprise adoption, especially for teams using either company's tooling.
- The tool drives coding agents that execute arbitrary shell commands and merge git worktrees; destructive risk depends heavily on policy configuration quality. Review defaults and keep approval gates enabled before deployment.
- govulncheck does not fail CI, and the locally replaced bubbletea fork is outside upstream vulnerability fixes; track these yourself.
- Single-maintainer project with bus factor 1; no visible CHANGELOG, so diff behavior release-by-release when upgrading.
What does this agent do, and when should you use it?
NTM is a pure-Go single binary that wraps tmux as a control plane for running multiple AI coding agents in parallel. It spawns labeled agent panes (Claude, Codex, Antigravity, Grok Build, with Gemini as legacy) inside named tmux sessions and exposes a dashboard and TUI command palette. Beyond session management, it integrates graph-aware work triage and auto-assignment via br/bv, Agent Mail coordination with file reservations, policy and two-person approval workflows for destructive commands, and durable state via checkpoints, timelines, and audit logs. For automation it offers --robot-* machine-readable CLI surfaces plus a local REST/SSE/WebSocket server (ntm serve) with a generated OpenAPI spec. The system is local-first and degrades gracefully when optional integrations such as Agent Mail or CASS are absent.
NTM creates named tmux sessions (ntm quick, ntm spawn), allocating agent panes via flags like --cc/--cod/--agy/--grok, with labeled swarms, worktree isolation (one ntm/<session>/<agent> branch per agent), and merge/cleanup flows. Operators dispatch prompts with ntm send, interrupt with ntm interrupt, monitor with ntm watch/activity/health, and inspect output with ntm diff/grep. Work triage runs through ntm work triage/next and ntm assign --auto against the br/bv work graph, gated by approval labels. A coordination layer provides ntm mail, ntm locks (with approval-gated force-release), and ntm coordinator auto-assign/digest. Safety uses ntm safety check, ntm policy, and ntm approve workflows. Durable state covers ntm checkpoint, ntm timeline, ntm audit, and resumable ntm pipeline runs. Automation surfaces include --robot-snapshot/--robot-send commands and ntm serve (REST /api/v1, SSE /events, WebSocket /ws, OpenAPI docs). Custom agent types load as TOML plugins from the agents/ directory, including a verified built-in Oh My Pi (omp) preset.
- A solo developer running 3-5 Claude/Codex panes on one project who wants a unified dashboard and command palette instead of raw tmux pane wrangling
- A tech lead who wants specific tasks auto-assigned to particular agents based on a br/bv work graph with an auditable assignment record
- A team needing multiple agents on one repo without conflicts, using --worktrees for isolated Git checkouts and Agent Mail for file reservations
- An engineer in a sensitive environment requiring policy gates and two-person approvals before destructive commands like git reset --hard
- Automation users driving agent swarms programmatically from scripts or CI via --robot-* JSON output or the ntm serve REST/WebSocket API
- Anyone running long multi-step agent pipelines (e.g. review.yaml) who needs resume-from-checkpoint after failures
What are this agent's strengths and limitations?
- One Go binary unifies session orchestration, work triage, safety approvals, coordination, and APIs — no glued-together scripts
- Destructive operations are approval-gated by default (e.g. locks force-release requires a second operator; self-approval is rejected), making safety core rather than bolt-on
- Strong durability design: checkpoints, timelines, audit logs, and resumable pipelines make interruptions recoverable
- Dual automation layers: local --robot-* JSON commands for scripting plus ntm serve with REST/SSE/WebSocket/OpenAPI for long-lived integrations
- Pluggable custom agent types via TOML files in agents/, with a verified built-in Oh My Pi preset, extending beyond built-in CLIs
- Intentionally tmux-centric with Linux and macOS as primary environments; no native Windows story
- Advanced features depend on external tools (br, bv, Agent Mail, CASS) that are unavailable when not configured
- Grok Build support is phase one only: automated prompt delivery, interrupt-with-message, restart, and restore-time relaunch fail closed
- No outside contributions accepted; PRs are not merged directly, fixes depend on the author's AI-assisted review flow
- License is MIT plus an additional rider (GitHub shows NOASSERTION), so compliance review is warranted before adoption
- Strict config loading (unknown fields are errors) and migration steps such as moving [health] settings to [resilience]
How do you install or deploy this agent?
Three options: 1) Install script: curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/ntm/main/install.sh?$(date +%s)" | bash -s -- --easy-mode; 2) Homebrew: brew install dicklesworthstone/tap/ntm; 3) From source: git clone https://github.com/Dicklesworthstone/ntm.git && cd ntm && go install ./cmd/ntm. Docker images (amd64/arm64) are available at ghcr.io/dicklesworthstone/ntm:1. Runtime requires tmux plus whichever agent CLIs you want to launch (Claude Code, Codex, Antigravity CLI, or Grok Build); verify with ntm deps -v.
How do you use this agent?
Enable shell integration: eval "$(ntm shell zsh)". Scaffold a project and spawn a mixed swarm: ntm quick api --template=go, then ntm spawn api --cc=2 --cod=1 --agy=1. Open operator surfaces: ntm dashboard api and ntm palette api. Dispatch work: ntm send api --cc "Map the auth layer and propose a refactor plan." Use ntm work triage to inspect the work graph and ntm assign payments --auto --strategy=dependency for automated assignment. Save a checkpoint: ntm checkpoint save api -m "before auth refactor". Start the local API: ntm serve --port 7337; for scripts, use ntm --robot-snapshot and related robot commands.