Shell scripts vs a manager for agent fleets

2026-09-28

Past three or four coding-agent sessions, your problem stops being model quality and starts being you. You’re answering prompts, hopping tmux panes, and.

---

Past three or four coding-agent sessions, your problem stops being model quality and starts being you. You’re answering prompts, hopping tmux panes, and guessing which agent is stuck or quietly off-mission.

This is where most people either grow a pile of “Herd X” shell/Python glue, or adopt a manager like Maxxwell. The core trade-off is simple: scripts buy raw flexibility; a manager buys a control plane.

What matters when you manage a herd of agents

Before comparing Herd X scripts to Maxxwell, it’s worth being explicit about the constraints.

Anthropic’s 2026 trends report is blunt: developers use AI in ~60% of their work, but can fully delegate only 0-20% of tasks. In ~400,000 Claude Code sessions from ~235,000 people, humans made most planning decisions; agents handled execution.

So the questions aren’t “can my agents write code?” but:

• How do I see what each session is doing?
• How do I keep drift and dead sessions from eating my day?
• How do I scale past five or ten concurrent lanes without breaking my own brain?

A good manager layer solves for:

• Visibility: per-session state, not just a scrollback
• Attention routing: what actually needs you right now
• Failure surfaces: where multi-agent systems usually go wrong
• Control: agents do the work; you decide what lands

Herd X scripts: power and maintenance in one bundle

Herd X scripts are the tmux layouts, shell loops, and Python glue you already have:

• Bash to launch N agent processes
• tmux or zellij panes for each
• A bit of Python to tail logs, send prompts, or replay context

You get three big advantages.

What Herd X scripts do well

1. Total flexibility Your scripts embody your workflow:
   • Custom prompts and bootstraps per agent
   • Tight coupling to your repos, build system, and test harness
   • Odd cases: “run agent 3 with a tiny context and weird environment vars”

1. No new dependency Everything runs:
   • In your terminal
   • Under your process supervisor
   • With your own logging and access patterns

1. Infinite hackability If you want to wire agents into a homegrown queue or CI step, you can:
   • Add a cron that kills stale sessions
   • Pipe outputs into a review script
   • Invent your own priority scheme

For 1-3 agents, this is enough. Your shell is the orchestration layer.

Where Herd X scripts break down past 5-10 sessions

The failure modes show up as soon as you treat the herd as a system instead of a set of processes.

From multi-agent research (1,600+ traces across 7 frameworks, 14 failure modes) and telemetry work on reasoning loops, the common problems cluster around:

• System design issues - unclear goals, overlapping responsibilities
• Inter-agent misalignment - two sessions solving slightly different problems
• Task verification gaps - nobody is checking whether the herd is still aimed correctly

In practice, your Herd X scripts usually fall short on:

1. Observability You get ps, tmux status lines, and some log files. You don’t get:
   • “this lane is waiting on you” vs “this lane is just slow”
   • “this session hasn’t produced output in 5 minutes” in human terms
   • A clear state model: working, idle, blocked, done

1. Attention routing When you have eight agents, your terminal is noise:
   • Every pane is scrolling
   • You alt-tab into whatever last screamed at you
   • You answer low-value questions while high-value work waits

1. Failure diagnosis When something goes wrong, these questions are hard to answer quickly:
   • Did this session stall, or is it on a long-running test?
   • Did it drift, or did my brief suck?
   • Which sessions are safe to kill vs need a human check?

1. Scaling the workflow to a team Homegrown scripts scale poorly:
   • Every engineer’s “herd” scripts diverge
   • Onboarding means explaining opaque tmux rituals
   • Debugging orchestration bugs becomes a mini-platform project

If you’re already at five or more agents at once, you will eventually end up writing:

• A crude dashboard
• Some ad-hoc state file per process
• A fragile scheme for “waiting on human” vs “running”

At that point you’ve reimplemented half of a manager.

Maxxwell: a manager for the agents you already run

Maxxwell treats this as a control-plane problem. It doesn’t try to be another coding agent. It manages the ones you already run: Claude Code, Codex, Cursor agents, or your own.

Mechanically:

• It’s a local desktop app plus a standalone CLI
• It runs unmodified workers as real terminal sessions
• It keeps credentials and model access local; you bring your own keys or subscriptions

No sign-up, no hosted control plane for normal local use.

Fleet visibility: every session in one window

Maxxwell puts each agent session in a lane with a readable state:

• working
• idle
• waiting on you
• not started
• needs sign-in
• blocked
• done
• dead
• not heard from (when it genuinely doesn’t know)
• plus a “possibly stalled” overlay when the signals look suspicious

You see, at a glance:

• Which sessions are doing useful work
• Which are safe to ignore for ten minutes
• Which are stuck on a trivial question
• Which might be quietly building the wrong thing

The system follows the brand’s point of view: say what you can’t verify. It uses “not heard from” instead of guessing “working”. A dashboard that is confidently wrong is worse than one that admits a gap.

Orchestrator seat: one brief, one conversation

On top of the lanes sits an orchestrator seat:

• It’s itself a real coding-agent session
• You start it from a written brief that describes goals and constraints
• You talk to it instead of twelve terminals

The orchestrator:

• Coordinates work across the herd
• Reports back what landed
• Distinguishes what it decided for you vs what needs your call

Anthropic’s studies show humans still own planning, agents own execution. The orchestrator is built around that fact: it raises decisions instead of hiding them.

Drafts rather than acts: you still press enter

One distinctive property: fleet controls draft rather than act.

Any control that would change the herd:

• Writes a fully formed, unsent sentence into the composer
• Stops

Nothing auto-runs. You are the one who presses enter.

This matters if you care about:

• Build integrity
• Review and tests
• Avoiding a “smart” orchestration layer that can quietly break main

Maxxwell is conducting, not autopilot. It does not claim to:

• Auto-detect drift and re-aim sessions
• Auto-compact or recycle context
• Restart work that stopped
• Run goal checks on its own schedule

It gives you:

• Live context-pressure readouts with tiered warnings
• A one-click compact when you decide context is too heavy
• Session lifetimes that outlive the app; quitting detaches, it never kills

Local-first: the herd survives your window

Sessions in Maxxwell:

• Are real processes you can attach to in a terminal
• Keep running when you quit the app
• Don’t require a server or account

Closing your laptop is not silently throwing away an hour of work.

Herd X vs Maxxwell: side-by-side comparison

Here’s a direct comparison for typical criteria.

For a deeper look at workflow patterns, see the related guide: herding coding agents without adding more noise.

Scaling beyond five or ten sessions

The scaling break-point is not high. Anthropic reports Claude Code users spend an average of ~20 hours per week in agentic workflows, and the share of GitHub projects with coding-agent activity more than doubled since late 2025.

Once multiple people are running 5+ parallel sessions, the coordination cost becomes visible.

How Herd X scripts scale

With scripts, scaling looks like:

• Adding more panes or windows
• Naming sessions carefully
• Writing utility scripts to kill, restart, or reprioritize jobs

Real-world symptoms:

• Things get brittle when one engineer’s scripts differ from another’s
• It’s hard to onboard new people into the orchestration logic
• Troubleshooting a stuck agent means reverse-engineering someone else’s shell

The failure taxonomy work (MAST, AgentTelemetry) shows that multi-agent systems fail mostly in reasoning loops and misaligned delegation. Ad-hoc scripts rarely model those explicitly; they treat everything as “a process with logs”.

How Maxxwell scales

With Maxxwell, scaling looks like:

• Adding more lanes to the same window
• Using the orchestrator to triage sessions
• Using one readable state vocabulary across sessions

You get:

• A shared definition of “blocked”, “waiting on you”, “possibly stalled”
• An orchestrator that separates what actually landed from what needs your call

You still do the thinking. The manager just compresses the overhead.

When to stick with scripts vs when to adopt Maxxwell

Stay with Herd X scripts if

• You rarely exceed 3-4 concurrent agent sessions
• You enjoy writing and maintaining orchestration glue
• Your herd is personal, and you don’t need other people to share your view

Adopt Maxxwell if

• You regularly run 5-10+ sessions and feel like you are the bottleneck
• You want one place to see what each agent is doing, with explicit state
• You care about keeping Claude/Codex/Cursor as-is, but want a manager above them
• You want fleet controls that draft rather than act, so the person presses enter

Most serious users start with scripts, then add a manager when the overhead starts to cost real hours.

FAQ: Herd X scripts vs Maxxwell

Does Maxxwell replace my existing coding agents?

No. Maxxwell manages the agents you already run.

Workers are unmodified Claude Code, Codex, Cursor agents, or your own tools, running as real terminal sessions you can attach to and take over at any moment.

Can I keep my custom scripts and still use Maxxwell?

Yes.

You can:

• Keep using your scripts for the parts of your setup Maxxwell doesn't cover
• Drop into a terminal any time to bypass the UI

Maxxwell is a control plane, not a replacement for your shell.

How does Maxxwell help detect stuck or mis-aimed agents?

Maxxwell marks each session with a state like working, idle, blocked, waiting on you, or not heard from, with a “possibly stalled” overlay when something looks off.

It does not silently assume “working” when it has no signal. You still decide whether a session is truly stuck or just slow, but you don’t have to infer that from logs alone.

Does Maxxwell automate agent decisions?

No.

Fleet controls draft changes instead of executing them:

• A control writes an unsent sentence into the composer
• You choose whether to send it

There is no background autopilot that re-aims sessions, restarts work, or runs goal checks on its own schedule.

What does Maxxwell cost and how is it deployed?

For individuals:

• Local app, free forever
• No sign-up, no hosted server

For teams:

• Paid tiers for teams

You bring your own model access: an API key or an existing Claude or ChatGPT/Codex subscription.

---

If you’re at the point where most of your day is spent answering agents rather than coding, it’s worth treating the herd as a system and giving yourself a manager.

---