Maxxwell by Rindler
Writing

Run four coding agents on one feature

2026-09-20

Most people hit the same wall with coding agents: the model is fast, but you’re stuck babysitting six terminals. The feature gets built, but only if you.

Most people hit the same wall with coding agents: the model is fast, but you’re stuck babysitting six terminals. The feature gets built, but only if you constantly route work, answer the same questions, and notice when one agent has quietly gone off-spec.

This tutorial walks through a concrete, end-to-end workflow where multiple AI coding agents handle design, implementation, tests, and docs for a single feature. Your job is to set goals, approve decisions, and intervene when it matters.

If you want more background first, the pillar piece AI coding agent orchestration: the complete guide for multi-agent development covers patterns and tradeoffs in depth. Here we’ll just build one working pipeline.

Scenario and prerequisites

We’ll ship a realistic feature:

Add email-based two-factor authentication (2FA) to a Django app, including UX copy, backend logic, tests, and docs.

We’ll orchestrate four roles:

You’ll need:

For orchestration, we’ll assume you’re using Maxxwell by Rindler because it gives you:

If you’re using tmux + shell aliases instead, you can still follow the steps conceptually.

Step 1: Create the feature brief and orchestrator

First, turn the feature into a short, explicit brief. This is the single source of truth for all agents.

Create briefs/2fa-email.md:

# Feature: Email-based Two-Factor Authentication (2FA)

## Goal
Require an email one-time code on login for accounts that have 2FA enabled.

## Constraints
- Stack: Django 4.x, Python 3.11
- Use existing User model (no new auth provider)
- No SMS, no third-party services

## Acceptance criteria
- When a user with 2FA enabled logs in successfully, they see a second step:
  - "We emailed a one-time code to your address ending in ***@example.com"
  - Input for 6-digit numeric code
- Code expires after 10 minutes
- 5 failed attempts lock 2FA for 15 minutes
- Unit tests cover:
  - Happy path (login + verify)
  - Expired code
  - Too many attempts
- Docs:
  - README section: "Email 2FA" with setup steps
  - User docs page: "Signing in with 2FA"

In Maxxwell:

  1. Start a new orchestrator session from this brief.
  2. Give it a name like feat/2fa-email/orchestrator.
  3. Tell it explicitly: its job is to coordinate other agents, not write all the code itself.

Example first message to the orchestrator:

You are the conductor for this feature: email-based 2FA as per briefs/2fa-email.md.

You do NOT write all the code. You:
- Plan the work
- Propose tasks to a Planner, Implementer, Tester, and Doc writer
- Summarize what landed and what needs my approval

Ask me before making repo-wide structural changes.

Now you have a single conversation that owns the feature.

Step 2: Stand up worker agents and assign roles

Next, create one worker session per role. In Maxxwell these are just your existing tools running in terminals.

Suggested sessions:

In each worker session, send a short role brief. You can have Maxxwell draft these via the orchestrator, then you press enter to send.

Example role brief for the planner:

You are the Planner for feature: email-based 2FA in a Django app.

Inputs:
- briefs/2fa-email.md
- Existing codebase in this repo

Deliverables:
- A written implementation plan in PLAN-2FA.md
- A list of files to touch
- Clear boundaries for Implementer, Tester, and Doc writer

Avoid making code changes. Focus on the plan.

Repeat for Implementer, Tester, Doc writer, with equally tight scopes:

The point is separation of concerns. Multi-agent workflows fall apart when every agent "does everything".

Step 3: Let the planner design the feature

Ask the orchestrator to instruct the planner to produce a concrete plan.

To the orchestrator:

First task: have the Planner design the implementation.

Ask it to produce PLAN-2FA.md with:
- Data model changes
- URL/view changes
- Templating/UI changes
- Config/feature flags
- Test plan

Draft the message you will send to the Planner.

Maxxwell will draft a message addressed to 2fa-planner. You review and send it.

In the planner session, wait for the output. When it’s done, you should get something like:

Skim the plan. You’re mainly checking for:

If changes are needed, reply in the planner session or ask the orchestrator to request revisions.

This step pays for itself: once you have a good plan, you can point every agent at the same document, and you’re less likely to get drift.

Step 4: Spin branches/worktrees and isolate execution

Even with good agents, you don’t want them fighting in the same working tree.

Create a feature branch and optional worktrees:

git fetch origin
git checkout -b feat/2fa-email origin/main

# Optional: separate worktrees per role
git worktree add ../wt-2fa-impl feat/2fa-email
git worktree add ../wt-2fa-test feat/2fa-email

Point each worker session at the right directory:

Tell the orchestrator you’ve created the branches/worktrees so it can mention paths explicitly when talking to workers.

Anthropic, Google, and OpenAI all recommend this kind of pipeline shape: plan, isolate, execute in parallel, validate, review, then merge. You’re wiring that pattern by hand, instead of hoping one giant agent improvises it.

Step 5: Route implementation work from the plan

Now turn the plan into implementation tasks.

To the orchestrator:

Use PLAN-2FA.md to create a sequence of implementation tasks for the Implementer.

Each task should:
- Touch a small set of files
- Be testable in isolation
- Include a quick manual check

Draft your first instruction to the Implementer, focusing only on data model and backend logic.

Again, Maxxwell drafts the message to 2fa-impl. You read it, fix anything off, then send.

In 2fa-impl, the agent now works on code. Your role:

You might run:

cd ../wt-2fa-impl
pytest tests/auth/test_2fa_email.py

Paste failures back to the Implementer or ask the Tester to take over (next step).

The critical thing: you are not micro-prompting every function. You’re approving task boundaries and diffs.

Step 6: Put a Tester in the loop early

Most agents are bad at testing when it’s bolted on at the end. Give the Tester a first-class seat.

In the Tester session, send a role-specific task:

You are the Tester for email-based 2FA.

First task:
- Create tests/auth/test_2fa_email.py
- Implement the tests described in PLAN-2FA.md acceptance criteria
- Assume views and models might not exist yet; mark tests xfail or skipped with clear TODOs.

Goal: a failing-but-structured test suite the Implementer can drive to green.

Now you can:

When tests fail, route the failure back:

This is where an orchestrator helps. Instead of you scanning logs and deciding who to ping, you can say to the orchestrator:

Tests in the Tester lane are failing with the following output: [paste].

Decide whether this is likely a code bug or a test bug, and draft a message to the correct worker asking them to fix it.

You still confirm the routing, but you’re offloading diagnosis and message-writing.

Step 7: Have a Doc writer follow behind the code

Docs and UX copy work better when they flow from an implementation that already exists.

In 2fa-docs:

You are the Doc writer for email-based 2FA.

Inputs:
- briefs/2fa-email.md
- PLAN-2FA.md
- Current implementation in this branch

Tasks:
1. Add a README section "Email 2FA" with setup steps for developers.
2. Create or update a user-facing doc page "Signing in with 2FA".
3. Propose UI strings for the 2FA prompt and error states.

Do not change Python code. Limit yourself to markdown/docs and string constants.

When the Implementer changes UX copy, tell them to keep strings centralized so the Doc writer can manage them (e.g., Django gettext messages or constants).

You can ask the orchestrator to:

This keeps the doc seat accurate without you having to re-explain the feature.

Step 8: Use the dashboard to triage attention, not output

By this point, you probably have 4+ active sessions. The bottleneck is deciding where to look.

Maxxwell’s session list gives each lane a state:

This matters because a lot of the pain devs report - "I can’t tell which of these is stuck and which is just slow" - is exactly this classification problem. The tools you already have don’t do it.

Use those states to drive your loop:

  1. Sort by waiting on you and unblock those first.
  2. Check blocked and either answer or reassign the task.
  3. Only then skim working sessions for spot checks.

You’re treating agents like a small team in standup, not a pile of terminals.

Step 9: Manage context pressure and long runs

Multi-agent workflows burn context quickly. Maxxwell gives you a live context-pressure readout with warnings as sessions get close to their limits.

When a lane is highly pressured:

Avoid:

You’re trying to keep each agent’s working memory clean so it doesn’t forget earlier decisions or start contradicting itself halfway through the feature.

Step 10: Review, report, and merge

When tests are green and docs are written, switch the system into review mode.

Ask the orchestrator for a return report:

Summarize the state of this feature:
- What code has landed (file list + short descriptions)
- What tests exist and their status
- What docs were added or updated
- Any open TODOs or assumptions

Separate clearly between things that are done and things that are waiting on me.

This report is where Maxxwell earns its "agent-of-agents" positioning. It tells you what landed vs what’s pending, instead of dumping raw logs.

Now you:

Then:

git add .
git commit -m "Add email-based 2FA"
git push origin feat/2fa-email

Open a PR, include the orchestrator’s summary as a starting point for the description, and get a human review as usual. Agents are part of your pipeline, not an excuse to skip review.

Work outlives the orchestrator window: Maxxwell detaches from sessions when you quit instead of killing them, so you can re-attach later if you need to revisit the feature.

Putting it all together as a repeatable pattern

What we just did is a practical template you can apply to other features:

  1. Single brief → one orchestrator seat
  2. Dedicated roles → planner, implementer, tester, docs
  3. Isolated workspaces → branch/worktrees per feature or per role
  4. Dashboard first → triage by session state, not by who shouted loudest
  5. Human gates → you press enter, you approve diffs, you merge

If you want to go deeper into patterns, tradeoffs, and DIY orchestration vs tools like Maxxwell, the main guide AI coding agent orchestration: the complete guide for multi-agent development breaks down more designs and compares them to what teams are doing with tmux scripts, ctx, Alera, and similar tools.

FAQ: orchestrating AI coding agents for feature delivery

How many agents is “too many” for a single feature?

For most features, 3-5 agents is the sweet spot:

Past that, coordination overhead grows faster than the benefit. Prefer reusing roles across tasks over adding more seats.

Do I need different models for each role?

No. You can run all roles on the same base model if that’s what you have access to.

Specializing helps, though:

The orchestration pattern (roles, handoffs, isolation) matters more than model diversity.

How do I detect when an agent is drifting or building the wrong thing?

There’s no magic autopilot here - you still need to watch for drift.

Practical checks:

If something looks off, redirect that worker with a corrected brief or cut over and edit the code yourself.

Can I run this entirely locally without sending my code to a SaaS?

Yes, if you pick local-first agents or self-hosted models.

Maxxwell itself runs locally, with no sign-up and no server. You bring your own keys or on-prem endpoints. The usual caveats apply: if you connect it to SaaS models, your data goes wherever those providers send it.

How much developer time does this actually save?

Industry surveys suggest the productivity gains are real but uneven:

The main time savings with orchestration come from:

Try it on one non-critical feature and measure: calendar time from brief to merged, and your actual hands-on minutes.