Maxxwell by Rindler
Writing

Running 10-30 coding agents without drowning

2026-10-22

By the end of this guide you’ll have a concrete Maxxwell workflow where:

By the end of this guide you’ll have a concrete Maxxwell workflow where:

This assumes you already run agents like Claude Code, Codex, or a Cursor agent today. The problem isn’t output quality; it’s knowing which session is stuck, which needs a decision, and which is happily building the wrong thing.

Once you’re running several agents at once, coordination becomes an actual engineering problem, not a curiosity.

Prerequisites

Before step 1, you need:

1. Define a narrow, testable goal for this herd

If you spin up a herd of agents without a goal, you get noise. You want one narrow objective per Maxxwell herd so states and layout mean something.

Concrete example goals:

Write this down as a short brief.

Template:

Goal: migrate payment logic to a separate service.
Constraints:
- Do not change public API responses.
- All new code must have tests.
- PR must be under 500 lines of diff.
Timebox:
- 2-3 hours total.

You’ll feed exactly this text into Maxxwell’s orchestrator seat.

Common failure:

2. Start Maxxwell and create an orchestrator seat from your brief

The orchestrator seat is a real coding-agent session with a written brief. It’s the one you talk to instead of twelve terminals. It doesn’t auto-pilot; it drafts plans and fleet commands, and you press enter.

Steps:

  1. Launch Maxxwell.
  2. Create a new session and select it as an orchestrator.
  3. Paste your goal brief into the initial prompt.
  4. Point it at the repo you care about.
  5. Bind it to your preferred model/runtime (for example Claude Code via your existing config).

Example prompt for the orchestrator:

You are the orchestrator for a small fleet of coding agents working on this repo.

Goal: extract payment logic into a new `payments-core` service while preserving
existing public APIs.

Constraints:
- Changes must be covered with tests.
- No direct DB access from controllers once refactor is done.
- Prefer small, isolated commits.

You coordinate, decide when to spawn or retire worker sessions, and report back:
- what work landed,
- what is waiting on me,
- what is blocked.

Always propose actions as sentences I can send to a worker. Do not run commands yourself.

Common failure:

3. Design a simple Maxxwell session layout by role

Dozens of sessions only work if you can glance and categorize. Start with a minimal layout and grow.

Recommended layout for ~10-20 agents:

Think in roles, not individual sessions:

Create Maxxwell sessions mapped to those roles, each backed by your existing agents.

Example session naming:

This becomes your Maxxwell herd view: one line per session, each with a clear role.

Common failure:

4. Tag and respect session states so you can triage at a glance

Maxxwell exposes readable session states such as:

There’s also a “possibly stalled” overlay when a session hasn’t produced output for a while.

Your job is to make those states meaningful.

Suggested policy per state:

Concretely:

Common failure:

5. Use Maxxwell’s herd view to keep the right sessions visible

The Maxxwell herd view puts all sessions in one window with their current state plus the “possibly stalled” overlay. The point is to avoid constantly cycling between terminals or IDE panes.

A practical pattern:

Example visual ordering:

  1. builder: controllers -> service [waiting on you, possibly stalled]
  2. migration: schema + backfill [blocked]
  3. builder: tests + fixtures [working]
  4. infra: CI and scripts [idle]
  5. legacy-spike: experiment [done]

This is the equivalent of a priority queue on your attention.

Common failure:

6. Drive all fleet changes through drafts, not direct commands

Maxxwell’s distinctive property is drafts rather than acts:

This is how you keep tests and builds trustworthy while still getting leverage.

Concrete pattern:

When you want to spin up a new worker from the orchestrator, you say:

Propose a new worker session focused on writing integration tests for the
`payments-core` service, and draft the command or sentence to start it.
Do not run it; I will send it myself.

The orchestrator responds with something like:

Create a new session named "builder: payments integration tests" bound to the
existing Claude Code runtime and start by listing all existing tests touching the
`Payment` model.

Maxxwell writes that as an unsent sentence into the fleet control composer. You read it, edit if needed, and press enter.

Common failure:

7. Attach to worker sessions when needed and treat them as real terminals

Maxxwell runs your workers as real terminal sessions. They’re your own tools: Claude, Codex, cursor-agent, custom scripts. You can attach and take over at any time.

Example flow:

  1. In the herd view, see migration: schema + backfill [blocked, possibly stalled].
  2. Attach to that session.
  3. You might see:
    Error: missing environment variable DATABASE_URL
  1. Fix the issue locally:
    export DATABASE_URL=postgres://localhost/payments
  1. Give the agent a short instruction:
    Env is fixed. Re-run the migration and report status.

Because sessions outlive the app, you can also quit Maxxwell and later reattach without killing any work. Closing your laptop is not a decision to throw away an hour of agent progress.

Common failure:

8. Track context pressure and compact when the warnings light up

Context is finite; you can’t just throw infinite context at a task. Maxxwell gives you a live context-pressure readout per session, with tiered warnings.

Typical tiers:

When it’s elevated or high, Maxxwell offers a one-click compact.

Concrete routine:

This keeps the agent from hallucinating old context that’s no longer in the window.

Common failure:

9. Use a return report to separate “landed” from “waiting on you”

By the time your herd finishes a run, you need a clean answer to three questions:

  1. What actually landed (commits, branches, migrations)?
  2. What still needs my decision?
  3. What died or stalled along the way?

Ask the orchestrator for a return report before you call the task done.

Example prompt to orchestrator:

Produce a concise return report for this herd, separating:
- work that has landed (with paths or branch names),
- items waiting on me (with concrete questions), and
- sessions that are done, dead, or not heard from.

Use one short section per worker session.

You should get something like:

Landed
- builder: controllers -> service
  - Implemented PaymentsService with methods X, Y.
  - Updated controllers A, B to call the service.
  - Branch: feature/payments-core-refactor.

Waiting on you
- builder: tests + fixtures
  - Needs a decision on whether to keep older flaky test suite.

Done/dead
- migration: schema + backfill [done]
  - Migration file: db/migrate/20260919_add_payments_core.rb
- legacy-spike: experiment [dead]
  - Session terminated after spike was discarded.

Treat this report like a mini-PR summary. It’s what you’d hand to a teammate.

Common failure:

10. Scale up to dozens of agents without losing the plot

Once you’ve run a few tasks this way, you can safely scale up the herd:

When you cross 15-20 sessions, discipline becomes mandatory:

This is also where a comparison against tools like Conductor or Herd/Herdr becomes interesting:

If you’re the person who already maintains custom tmux scripts or shell aliases for “multi-agent work”, Maxxwell is the next abstraction up: a herd view and orchestrator seat that doesn’t steal your terminals.

FAQs and troubleshooting

How many agents should I start with in Maxxwell?

Start with 3-5 worker sessions plus one orchestrator. Once you can answer “which lane is waiting on me?” without thinking, grow to 10-15. Above that, tighten your naming and state discipline.

What’s the difference between “working”, “idle”, and “possibly stalled”?

How do I keep agents from building the wrong thing for 20 minutes?

Use a combination of:

When a lane drifts, stop it and re-brief; Maxxwell doesn’t auto-correct drift for you.

Can Maxxwell restart or recycle stuck sessions automatically?

No. The current release does not automatically restart work, recycle context, or re-aim a session. It makes state visible, gives you context-pressure warnings, and lets you compact or restart intentionally.

How does Maxxwell compare to my existing tmux + shell aliases setup?

You can think of Maxxwell as:

If your current scripts already name, tag, and monitor 10+ sessions cleanly, Maxxwell reduces the glue code you maintain and adds honest state tracking on top.