Maxxwell by Rindler
Writing

Your First Week Running Multiple Coding Agents

2026-09-22

Past two or three agent sessions, the model stops being the bottleneck. You do.

Past two or three agent sessions, the model stops being the bottleneck. You do.

You spend your day answering twelve terminals, trying to remember which agent is doing what, and whether the one that went quiet is working or just waiting on you.

This walkthrough is about your first agent-native coding workflow in Maxxwell: one orchestrator, several workers, and you staying the person who presses enter.

What you get at the end of this tutorial

By the end of this first week, you will have:

This is not a toy demo. The example assumes a real codebase and CI.

Prerequisites: what needs to be in place

You don’t need to change your stack. You do need a few basics ready.

On your machine:

Access and keys:

Mindset:

Step 1: Install Maxxwell and connect your agents

Maxxwell runs locally. No account, no hosted control plane.

1.1 Download and install

  1. Go to https://maxxwell.dev.
  2. Download the desktop app for your OS (or the CLI for macOS/Linux).
  3. Install as you would any other app.

If you prefer CLI first, the pattern looks like this (exact command may differ depending on package manager; check the docs):

Check the docs for the current install command for your platform.

1.2 Configure model access

Maxxwell uses the agents you already run; it doesn’t ship its own model.

  1. Open Maxxwell.
  2. Open settings.
  3. Add your keys or point it at the agent tools you already run (claude, codex, cursor-agent).

You’re not giving Maxxwell your codebase. It just launches your existing tools in terminal sessions it can track.

Step 2: Pick a real project and define a concrete goal

Don’t test multi-agent workflows on a toy “hello world” task. You want something that:

Example goal:

“Add rate-limited API keys to our internal service:

This is the goal you’ll give to the orchestrator seat.

2.1 Create a feature branch or worktree

Keep agent work off main.

cd ~/code/your-service

# Option A: simple branch
git switch -c feature/api-keys

# Option B: separate worktree (good for multiple agents)
git worktree add ../your-service-api-keys feature/api-keys
cd ../your-service-api-keys

Use the worktree path as the working directory for your agents.

Step 3: Launch the orchestrator session in Maxxwell

Maxxwell’s orchestrator seat is just another agent session, but briefed at a higher level.

3.1 Create a new orchestrator from a written brief

  1. In Maxxwell, click New orchestrator.
  2. Set the working directory to your project/worktree.
  3. Paste a written brief. For example:
You are the orchestrator for a set of coding agents working on the same repo.

Goal: Add API key support to our internal service.

Constraints:
- Do NOT push to main or change CI settings without my explicit confirmation.
- Prefer creating new modules over editing shared core utilities.
- Every code change must be covered by tests.

Available tools:
- worker-web: a coding agent focused on the web/admin UI.
- worker-api: a coding agent focused on backend APIs.
- worker-ci: a coding agent handling test fixes and CI wiring.

Your job:
- Break the goal into tasks and assign them to workers.
- Ask me before making repo-wide decisions.
- Report back what landed, what is in progress, and what is blocked or waiting on me.
  1. Start the orchestrator session.

You now have a single chat where you talk about goals, not line edits.

Step 4: Spin up worker agents as real terminal sessions

Workers in Maxxwell are your existing agents running in terminal seats. They’re not wrapped or rewritten.

4.1 Launch workers from the orchestrator

In the orchestrator chat, you can say:

Start worker-api and worker-web in this repo.
Have worker-api focus on backend endpoints for API keys.
Have worker-web focus on the admin dashboard page.

Maxxwell will draft the actual fleet control (the commands to start workers) into the composer. You review, then press enter.

Nothing runs until you send it.

Step 5: Understand Maxxwell’s session states

The point of Maxxwell is seeing at a glance which agent needs you and which is fine.

Each session has a state label, for example:

There’s also a “possibly stalled” overlay if something has been in the same state for too long.

This is the answer to “which of these is stuck and which is just slow?”

Step 6: Run your first multi-agent workflow

With orchestrator and workers live, you can run your first end-to-end workflow.

6.1 Break the goal into tasks (in the orchestrator)

In the orchestrator seat, paste your goal and ask for a plan:

We are on branch feature/api-keys.

Break the goal into 4-6 tasks.
Assign:
- Backend work to worker-api.
- UI work to worker-web.
- Test and CI work to worker-ci.

Only start tasks that are safe to run in parallel.
Return the task list and which worker will handle each.

The orchestrator replies with a plan. It might also suggest concrete commands.

6.2 Dispatch tasks via fleet controls (drafts, not actions)

When you ask the orchestrator to “tell worker-api to implement X”, Maxxwell does something specific:

@worker-api Implement the /api/keys endpoints:
- Add CRUD operations to the existing service.
- Add rate limiting at 100 requests/min per key.
- Add tests under tests/api/keys/.

Use branch feature/api-keys.

This property is deliberate: Maxxwell drafts, you act. You stay in control of anything that changes the fleet.

6.3 Watch progress from one window

As workers run:

Your job is to:

You’re no longer polling eight terminals by hand.

Step 7: Handle stalls and drift without losing control

The biggest fear with multiple agents is silent drift: an agent confidently building the wrong thing for twenty minutes.

7.1 Spot stalled or blocked sessions

If a worker shows possibly stalled with working, click in and scroll.

Look for:

If state is blocked, Maxxwell will show the last error where it can.

7.2 Take over a worker session directly

Any worker is a real terminal session you can attach to.

When you detach, Maxxwell keeps the session alive. Quitting Maxxwell detaches; it never kills sessions.

7.3 Re-aim work manually

Maxxwell does not auto-correct drift or restart work.

If a task is going wrong:

  1. Stop the current command/flow in the worker.
  2. Update the plan in the orchestrator seat.
  3. Draft a new instruction to the worker and send it.

You remain the scheduler.

Step 8: Integrate with git and CI

A workflow is only useful if it fits your existing git and CI habits.

8.1 Keep each agent on a known branch

A simple pattern:

A slightly safer pattern:

You can wire this into your orchestrator brief:

Assign worker-api to branch feature/api-keys-api.
Assign worker-web to branch feature/api-keys-ui.
Assign worker-ci to branch feature/api-keys-ci.

Do not push any branch without my explicit confirmation.

8.2 Run tests and CI locally from workers

Have worker-ci own the local test loop:

@worker-ci

Set up a fast test loop for this project.
Your job is to run tests after each significant change and fix trivial test failures.
Ask me before changing CI configuration files.

You’ll see test failures and fixes as normal terminal output, with Maxxwell tracking status.

8.3 Review before anything lands on main

Use your normal review flow:

git switch feature/api-keys
# or whichever branch the agents used

git log --oneline

git diff origin/main...

Then:

Maxxwell’s return report helps here: it separates what actually landed from what’s still waiting on you.

Step 9: Use context pressure and compaction instead of blind retries

Long-running agent sessions hit context limits. Maxxwell exposes this so you don’t fly blind.

9.1 Watch context pressure

Each session shows a live context-pressure indicator, with tiered warnings.

When you’re at critical, don’t just keep prompting.

9.2 Compact on purpose

Maxxwell gives you a one-click compact per session.

Compaction is something you trigger; Maxxwell never compacts or recycles a session's context on its own.

Use compaction before big new tasks, not after the model starts hallucinating missing context.

Step 10: The rest of your first week: tighten the loop

By mid-week, you’ll have a feel for the mechanics. The rest is tightening loops.

Patterns to adopt:

The problem is no longer whether agents help, but how to run more than one without losing the plot.

FAQ: your first week with Maxxwell and multi-agents

How is Maxxwell different from VS Code’s Agent Sessions view?

VS Code’s Agent Sessions view is tied to that editor and its agents.

Maxxwell is a separate, local control plane that runs whatever agents you already use in real terminal sessions. You can attach to any worker, use Vim, tmux, or your existing scripts, and nothing is wrapped or hidden.

Can I use Maxxwell with just one agent?

You can, but you probably shouldn’t.

The value shows up once you have at least two or three concurrent sessions and you’re the bottleneck coordinating them. If you only ever run a single agent, stick with your current setup.

Does Maxxwell automatically restart stuck agents or re-aim them?

No.

Maxxwell surfaces when a session is blocked or possibly stalled and lets you attach, fix, or re-aim it. It doesn’t auto-restart work, auto-correct drift, or run goal checks on its own schedule. You stay responsible for decisions.

Is any of this data sent to a server?

No.

Maxxwell runs locally. There is no required Maxxwell account or hosted control plane for ordinary use. Your model traffic goes where it already goes (Anthropic, OpenAI, etc.), using your keys or subscriptions.

How do I introduce this to a team?

The pattern most teams follow:

  1. One engineer tries Maxxwell on a personal or team-owned repo for a week.
  2. They document a simple “orchestrator + 2 workers” workflow in the team wiki.
  3. A small group adopts it for one project.
  4. The team refines conventions (branch names, CI patterns, review gates).

The principle is the same either way: run pilots, validate outputs, and keep humans in the loop instead of flipping a switch for the whole org.