Writing

Herd view vs tmux for supervising agents

2026-09-30

You already know how to run more agents. The problem is supervising them without spending your whole day in tab management and half-read transcripts.

This is a comparison of two concrete ways to do that:

tmux and other terminal multiplexers wired into DIY dashboards
Maxxwell’s herd view and herd-oriented workflow

The test is simple: visibility across repos, mental overhead, and how fast you can spot an agent that’s idle, blocked, or off-spec.

What you actually need from agent oversight

Once you’re running 3-8 coding agents in parallel, the limiting factor isn’t tokens or model quality. It’s your attention.

Recent data backs that up:

84% of developers are using or planning to use AI tools, and over half of pros use them daily (Stack Overflow 2025).
Only 29% trust AI outputs to be accurate, and 87% are concerned about AI agents’ accuracy.
Microsoft’s 2025 Work Trend Index says 80% of employees lack time and energy to meet expectations.

For multi-agent coding, oversight needs to give you, at a glance:

What each agent is doing and where (repo, branch, task).
How close it is to done and whether something landed on disk or in git.
Whether it’s waiting on you, blocked, possibly stalled, or just running a long test.
Enough context to decide “ship, re-aim, or kill” without rereading 500 lines of transcript.

tmux gets you durable sessions and panes. The question is whether that’s enough.

tmux as a multi-agent dashboard: what it does well

tmux is still the right answer for a lot of plumbing:

Sessions survive SSH disconnects and local crashes.
Windows and panes let you see multiple agents at once.
Detach/reattach lets work outlive the terminal.

A typical tmux-based setup for agent oversight looks like:

# one session per agent
$ tmux new -s agent-api
$ tmux new -s agent-frontend
$ tmux new -s agent-infra

# attach when you need to
$ tmux attach -t agent-api

On top of this, teams layer:

Custom status bars showing repo names, branches, and maybe a timer.
Scripts that rename windows like api:running, frontend:blocked, infra:idle.
Tools like tmux-agents that use hooks or screen-scraping to push state labels.

This works because:

You keep your real terminal and your existing agent CLI tools.
You can always drop into a pane and drive the agent yourself.
It’s scriptable, and you probably already have tmux muscle memory.

If your constraint is “I want one keyboard to control five shells”, tmux is close to optimal.

Where tmux dashboards start to fall over

The tmux manual is explicit: its primitives are sessions, windows, panes, key bindings, and a status line. There is no native concept of:

idle vs working vs blocked
needs sign-in or auth
possibly stalled

So every “tmux dashboard monitor multiple sessions” setup has to bolt those concepts onto tmux itself.

That has some consistent failure modes:

State detection is fragile
- Tools like tmux-agents depend on hooks and sometimes screen-scraping.
- If your agent CLI changes its output format, your “blocked” detection quietly stops working.
- Terminal multiplexers can’t reliably tell “waiting for user” from “long-running curl” without brittle heuristics.

State is pushed, not queried
- Each agent has to cooperate: write to a file, emit a special token, or call a hook.
- You end up modifying agents or wrapping them, which breaks the “unmodified tools” property.

No shared semantics across repos
- A pane doesn’t know which git worktree it’s working in.
- tmux doesn’t track “this agent owns branch agent/frontend-auth in repo X”.
- CommandSlate and ctx both call out this problem: by 3-4 agents, you stop being able to remember which agent is on which branch.

Mental overhead scales faster than sessions
- You’re carrying in your head:
  - which tmux session maps to which agent
  - which pane corresponds to which repo
  - whether “window 3” finished or just scrolled off the error
- ICSE’s “Breaking the Flow” work shows interruptions and task switching have measurable impact on code writing, comprehension, and review.
- A dashboard that forces you to re-parse logs in each pane is another interruption, not a fix.

The net effect: tmux is great session plumbing, but it stays plumbing. It never becomes a herd view.

Maxxwell herd view: one window per herd, not per shell

Maxxwell starts where tmux stops. It treats your coding agents as a herd and gives each a lane with explicit state.

The core pieces:

Herd view: one window showing every session, across repos.
Each lane has a readable state: working, idle, waiting on you, not started, needs sign-in, blocked, done, dead, not heard from, plus a possibly stalled overlay.
Orchestrator seat: a dedicated coding-agent session driven from a written brief.
- You talk to the orchestrator instead of twelve terminals.
- It reports what landed, what it decided for you, and what needs your call.

Crucially:

Workers are your own unmodified tools: Claude, Codex, Cursor-agent, etc.
They run as real terminal sessions you can attach to and take over at any moment.
Sessions outlive the app: quitting Maxxwell detaches, it never kills.

This is not “another copilot.” It is an agent-of-agents: it owns goals and visibility, not generation.

Visibility across repos: tmux panes vs herd view

If you’re asking how to monitor multiple AI agents across several repos, the question is: from one surface, can you answer “who is doing what, where, and how far along?”

tmux

Knows nothing about repos or branches by default.
You can embed repo names and git status into the tmux status bar with shell scripting.
Isolation is manual: you choose the working directory before starting the agent.
You track associations like session:agent-api → repo:services/api by convention and memory.

Maxxwell herd view

Treats “session + repo + task” as a unit you can see in one lane.
Makes it obvious which workers are attached to which repositories.
Returns a report separating:
- what actually landed in git or on disk
- what is still waiting on you
- what it chose to decide itself

Tools like ctx and GitHub Copilot app are converging on similar ideas: isolated worktrees, transcripts, artifacts, and a merge queue. Maxxwell sits in that same conceptual space but stays local and model-agnostic.

For “Maxxwell vs tmux” on visibility, the distinction is:

tmux: you remember which pane is which.
Maxxwell: the herd view remembers and shows you.

Mental overhead: remembering panes vs reading states

The Stack Overflow leader summary calls out tool overload explicitly: too many surfaces undermines productivity.

tmux leans into surfaces. Maxxwell compresses them.

tmux mental model

You juggle:

Session names (agents, agents-2, infra).
Window indexes (1:api, 2:web, 3:db-migrations).
Pane splits, each with its own prompt and scroll history.
Custom markers (e.g. a trailing * in the status bar) to mean “blocked” or “waiting.”

There is no single, canonical “herd state.” You build one out of text and conventions.

Maxxwell mental model

You read:

A single herd view, one lane per worker.
A small, finite state vocabulary: working, idle, blocked, waiting on you, etc.
A context-pressure readout with tiered warnings when sessions are pushing token limits, plus a one-click compact.

Because states are explicit and shared across all sessions, you aren’t inventing semantics per repo.

The payoff is simple: the number of agents doesn’t explode the number of things you must remember.

Detecting idle, blocked, or off-spec agents

This is the core of “which actually scales agent oversight.” How quickly can you spot that:

the agent building auth flows has gone idle
the infra agent is blocked on a missing kubectl context
the frontend agent confidently started building the wrong component

tmux-based detection

Typical patterns:

Idle: scroll stops; cursor sits at a prompt. You notice when you glance at the pane.
Blocked: recurring error lines; a red text pattern. You scan logs to find it.
Off-spec: only obvious once you read enough of the transcript or diff to realize it.

With tooling like tmux-agents, you can improve this:

Agents emit state tokens that are parsed into tmux window titles.
Screen-scraping looks for prompts or patterns to infer “waiting” vs “running.”

But nothing in tmux itself knows why an agent is idle or whether “no output for 5 minutes” is fine or a problem. You end up eyeballing.

Maxxwell herd view detection

Maxxwell makes blocked and idle states first-class:

Every lane carries a readable state, not an inferred one.
When Maxxwell cannot confirm a state, it says “not heard from” instead of guessing “working.”
When a session looks stalled, you see a “possibly stalled” overlay.

On top of that:

You see which agents are waiting on you rather than pretending to work.
The orchestrator seat can summarize: “frontend agent implemented component X, tests pass, waiting for review,” vs “infra agent blocked on missing AWS credentials.”

Maxxwell does not auto-correct drift or restart work by itself. Conducting is real, autopilot is not.

But for oversight, that’s the important line: you get very fast answers to “which thing needs my attention” without the system silently re-aiming agents in the background.

When to stick with tmux, and when Maxxwell is the better fit

If you’re running one or two agents and rarely parallelize across repos, tmux plus a couple of shell aliases is fine:

You get durable sessions.
You keep full control.
Oversight is mostly “look at the pane.”

Once you move into herd-oriented workflow - multiple agents, multiple repos, tasks queued up - tmux turns into a coordination tax:

You become the bottleneck: eight sessions open, you’re the slowest part.
You cannot tell which ones are stuck vs just slow.
One of them confidently builds the wrong thing for twenty minutes before you notice.

In that mode, Maxxwell is built for you:

One herd view instead of a dozen terminals.
Clear session states and “possibly stalled” overlays.
An orchestrator seat that you talk to like you talk to your agents today.
Fleet controls that draft rather than act: anything that would change the herd writes a sentence into the composer, and you stay the one who presses enter.
Local, no sign-up, no server; bring your own key or existing Claude / ChatGPT / Codex subscription.

For software team workflows where several people are running agents at once:

Sessions outlive the app, so closing a laptop isn’t a decision to throw away an hour of work.

FAQ

1. Is Maxxwell a replacement for tmux?

No. tmux is still the low-level session multiplexer.

Maxxwell sits above it as an agent-of-agents:

Workers run as real terminal sessions you can attach to.
Maxxwell gives you herd view, explicit states, and orchestration.

You can think of it as “tmux + semantics + a conductor,” not a substitute for tmux.

2. How does Maxxwell compare to tools like Herd, Helmor, or ctx?

All of these live in the multi-agent AI coding orchestration 2026 category.

Roughly:

Herd, Helmor, The Cog, Addy, Acepe: multi-agent IDEs/workbenches with their own views, often tightly integrated with specific models or cloud workflows.
ctx: local-first with strong worktree isolation, transcripts, artifacts, and a merge queue.
Maxxwell: agent-of-agents that stays local, model-agnostic, and keeps workers as unmodified terminals you can drive directly.

If you already trust your agents and terminal tooling, Maxxwell is aimed at managing them, not replacing them.

3. Can Maxxwell automatically detect drift and fix it?

No.

Maxxwell will:

Show you readable states per session.
Surface “possibly stalled” and context-pressure.
Make it obvious which agent is off-spec once you inspect the lane.

It does not:

Automatically detect drift and re-aim a session.
Automatically compact or recycle context on its own.
Restart stopped work.
Run goal checks on its own schedule.

You stay the one making those calls.

4. How does Maxxwell help spot idle or blocked agents faster than tmux?

Maxxwell:

Assigns explicit states: idle, blocked, waiting on you, etc.
Uses a possibly stalled overlay when it can’t confirm progress.
Says “not heard from” rather than guessing.

tmux:

Shows panes and scrollback; you infer states from output.
Any “blocked” indicator is a script or plugin layered on top, often using heuristics.

That difference is what makes Maxxwell herd view more scalable once you have a real herd.

5. Do I lose control if I let Maxxwell orchestrate my agents?

No.

Maxxwell is designed around a simple rule: the person presses enter.

Fleet controls draft rather than act: they write fully formed, unsent sentences into the composer.
Nothing changes the herd until you send it.
You can attach to any worker session at any time and take over mid-sentence.

It gives you leverage without hiding what’s happening under automation.