Orchestrating agents: greenfield vs legacy

2026-09-09

Most teams now have more AI output than attention. The real problem is how to run and coordinate multiple AI coding agents without breaking prod or wasting.

---

Most teams now have more AI output than attention. The real problem is how to run and coordinate multiple AI coding agents without breaking prod or wasting days on the wrong work.

This piece is an AI coding agents orchestration platform developers comparison for one specific decision: how you orchestrate agents for greenfield builds versus legacy migrations. It complements the harness-level patterns in AI coding agent orchestration: the complete guide for multi-agent development, and focuses on risk management, discovery, and refactoring coordination.

Why greenfield vs legacy orchestration diverge

For brand-new systems, the constraint is throughput. For legacy codebases, the constraint is risk.

Industry data matches what you've probably felt:

• OpenAI's harness engineering case study describes an internal product built with 0 lines of manually written code, ~1,500 PRs, ~1M LOC, and 3 engineers over about five months, mostly agents from an empty repo (OpenAI, 2025).
• In contrast, the U.S. GAO reports that federal agencies still spend ~80% of IT funding on operations and maintenance, and by early 2025 had finished only 3 of 10 critical legacy modernizations started in 2019 (GAO-25-107795).

Greenfield flows can tolerate missteps. Legacy systems are anchor points with hidden business rules; orchestration has to be about containment and auditability, not just speed.

Orchestration for greenfield builds: multi-agent AI coding IDE orchestration

When you're building from an empty repo, you can treat agents like a high-throughput, long-running team. OpenAI's harness engineering example and Anthropic's multiagent experiments give a feel for the ceiling here.

Key patterns:

• High autonomy, few gates
  • One orchestration agent owns the final answer (OpenAI's "manager" pattern).
  • Specialists (UI, backend, infra, docs) act as tools: they take structured briefs and return PRs or patches.

• Parallelism over caution
  • Anthropic's parallel compiler experiment ran 16 agents, ~2,000 Claude Code sessions, and spent about $20k in API costs to build a 100k-line Rust C compiler that compiles Linux 6.9 (Anthropic, 2024).
  • The orchestration concern wasn't "will this break prod," it was "are we exploiting parallelism and keeping the agents fed?"

• Monorepo as coordination spine
  • Greenfield agents can standardize on one repo and one CI pipeline.
  • Orchestrator agents:
    • queue work units ("implement auth service", "write terraform for staging"),
    • assign them to workers,
    • merge when tests pass.

• Discovery is design, not forensics
  • Discovery agents focus on user requirements, architecture options, and interface specs.
  • You can afford to rewrite early decisions; nothing fights back with 10-year-old data contracts.

A simple greenfield harness in 2026 often looks like:

# manager: reads a product brief and owns the roadmap
claude-code --session manager --prompt-file product_brief.md

# workers: attached by the manager via tools / function calls
claude-code --session api_worker
claude-code --session ui_worker
claude-code --session infra_worker

The orchestration problem is making sure the manager has visibility and tooling to slice work, not guardrails against legacy drag.

Orchestration for legacy migrations: multi-agent AI coding IDE orchestration under constraints

Legacy migrations are the opposite. You're strangling a monolith or displacing critical systems where you don't control all the invariants.

Three sources line up on the right primitives:

• OpenAI's sandboxed code-migration cookbook explicitly warns that "one massive migration PR is hard to review and risky to merge," and pushes one scoped task at a time in a controlled environment with tests and audit logs (OpenAI, 2025).
• Martin Fowler's Strangler Fig pattern recommends gradual replacement, with frequent releases and bi-directional asset migration to reduce risk (Fowler, 2004).
• An ACM 2024 review found 3,460 candidate modernization studies, 126 included, and 8 common strategies; the dominant drivers were cost reduction, performance/scalability, and reduced complexity (ACM, 2024).

What this means for agent orchestration legacy code migration:

• Tight scoping per agent session
  • Give each migration agent one slice: "extract billing from monolith into service," "move reporting to new schema," etc.
  • Each slice has a harness: sandboxed environment, specific tests, explicit rollback.

• Discovery agents for reality, not theory
  • Before any refactor, run agents to:
    • enumerate entry points,
    • infer domain concepts from code and data,
    • map dependencies (DB tables, batch jobs, external services).

• Staged handoffs instead of free-running teams
  • Use manager-owns-answer orchestration: one orchestrator agent stays in charge.
  • Specialists act as tools: "run static analysis on module X," "generate migration plan," "rewrite this interface and mock external deps."

• Risk primitives baked into the harness
  • Isolation: agents work in sandboxes cloned from main.
  • Auditable output: every patch is a PR with clear diffs and tests.
  • Incremental release: many small PRs, strangler-style, instead of one giant cut-over.

Concrete harness structure for legacy work

A minimal recipe that respects risk:

# 1. Clone a sandbox per migration task
TASK_ID=migrate-billing

git clone [email protected]:org/monolith.git sandboxes/$TASK_ID
cd sandboxes/$TASK_ID

# 2. Start a scoped migration agent session (Claude Code or similar)
claude-code \
  --session migrate_billing_1 \
  --working-dir sandboxes/$TASK_ID \
  --prompt-file prompts/migrate_billing.md

# 3. Run tests inside the sandbox, never directly on main
pytest tests/billing --maxfail=1

# 4. When green, open a PR from the sandbox to main
# (use your normal git tooling / CI)

OpenAI's cookbook calls out this pattern explicitly: single-task agents, sandboxed repos, and CI gates at each merge. It's slower than shipping everything from scratch, but it's what keeps you from quietly breaking invoicing.

Parallel vs staged workflows: throughput vs control

Google's DORA 2025 report is blunt: AI is an amplifier. Teams with strong systems get more benefit; weak workflows get "localized pockets of productivity" that don't change delivery outcomes. They also saw AI increase throughput but decrease stability (DORA 2025).

That's the orchestration trade-off:

• Greenfield: you accept some instability because there is no existing user traffic on your new system.
• Legacy: instability is a production incident.

So:

• Use parallel multiagent teams where it's safe to do so: greenfield features, internal tooling, non-critical pipelines.
• Use staged, gated orchestration for anything that touches money, compliance, or key business flows.

Anthropic's 2026 State of AI Agents report backs this: 57% of orgs deploy agents for multi-stage workflows, 16% have cross-team processes, and 80%+ report ROI, but long-lived peer agents are still "in their infancy" and work best on highly parallelizable problems (Anthropic, 2026; Anthropic multiagent).

Managing the human bottleneck in AI coding agents orchestration

Anthropic analyzed ~400k Claude Code sessions from ~235k users and found people spend ~20 hours per week in Claude Code; debugging time dropped by nearly half, and typical task value rose ~25% over seven months (Anthropic, 2025). The bottleneck now is your attention, not the agents.

You see this when:

• You have 8+ sessions open and can't tell which one is stuck.
• A migration agent happily builds the wrong thing for 20 minutes.
• You spend all day answering questions the agent could decide with context.

The orchestration layer has to:

• Expose session state in one place.
• Reduce decision interruptions to only the ones that actually need a human.
• Preserve control over what lands on main.

The pillar guide covers these harness-level patterns in detail: see the sections on fleet dashboards and human-in-the-loop decision boundaries in AI coding agent orchestration: the complete guide for multi-agent development.

Maxxwell vs similar tools, feature and workflow comparison (2026)

If you're already running Claude Code, Codex, Cursor-agent or similar, the question isn't "which agent," it's "what manages them." This is where Maxxwell by Rindler sits.

Maxxwell is an agent of agents, not a copilot. It runs locally (macOS, Linux, Windows) and manages your existing coding agents as real terminal sessions. Compatibility today:

• Claude Code (Anthropic, 2025+): via CLI or API key.
• OpenAI Codex / GPT-4-o code agents: via OpenAI API.
• Cursor-agent and other IDE agents: via their CLI or remote tools.

Other options in this space include:

• DIY tmux / zellij scripts:
  • Pros: total control, zero extra moving parts.
  • Cons: no semantic session states, no cross-session orchestrator; everything is manual.

• Web dashboards from model vendors (OpenAI, Anthropic):
  • Pros: integrated with their orchestration SDKs, good for single-vendor agent fleets.
  • Cons: browser-bound; hard to integrate with your local tools, and usually not managing real terminal sessions.

Where Maxxwell differs:

• One window with explicit session states per lane:
  • working - agent is actively generating.
  • idle - session alive, no current activity.
  • waiting_on_human - agent stopped for user input or confirmation.
  • not_started - lane created, agent not yet invoked.
  • needs_sign_in - upstream tool requires auth/API key.
  • blocked - hard error (e.g., CI failure) that stops progress.
  • done - agent finished its assigned task.
  • dead - underlying process exited unexpectedly.
  • not_heard_from - Maxxwell cannot verify state from the worker.

• An orchestrator seat that is itself a coding agent session started from a written brief:
  • You talk to one orchestrator instead of twelve terminals.
  • It reports what landed, what it decided for you, and what still needs your call.

• Drafts rather than acts:
  • Any fleet control that would change sessions writes a fully formed but unsent command into the composer.
  • You stay the one who presses enter; Maxxwell never executes session-changing commands without you.

• Sessions outlive the app:
  • Quitting Maxxwell detaches; it never kills workers.
  • Close your laptop lid and the work keeps running under your normal terminal / process manager.

Maxxwell fits both greenfield and legacy orchestration:

• Greenfield: orchestrator seat owns the roadmap, workers run your own tools for features, infra, docs.
• Legacy: the orchestrator seat helps you coordinate discovery, migration and verification workers, while the state view makes it clear which migration slice is blocked or waiting on you.</br>

Docs and integration details: see the product documentation at https://maxxwell.rindler.io/docs (URL subject to change; treat as the canonical reference).

Sample CLI / data model for integrating agent sessions

To plug existing agents into a Maxxwell-style harness, you need:

1. Authentication
   • Export model keys in your shell:

export ANTHROPIC_API_KEY=...
export OPENAI_API_KEY=...

1. Session descriptors
   • Maxxwell tracks sessions as simple records; a minimal JSON shape:

{
  "id": "session-123",
  "tool": "claude-code",
  "status": "working",
  "working_dir": "sandboxes/migrate-billing",
  "brief": "Migrate billing module to new service architecture",
  "created_at": "2026-08-29T10:03:00Z"
}

1. Harness commands
   • Example: start a new migration worker from the orchestrator seat:

# illustrative only - not a real Maxxwell command surface
maxxwell start \
  --id migrate-billing-1 \
  --tool claude-code \
  --working-dir sandboxes/migrate-billing \
  --brief-file prompts/migrate_billing.md

1. CI hooks
   • Treat agent output like any other patch:

# in your CI
pytest tests/billing --maxfail=1

This is the pattern described more abstractly in the pillar article's sections on harness APIs and CI integration hooks.

Comparison table: greenfield vs legacy agent orchestration

Below is a machine-readable table summarizing orchestration differences.

FAQ: common orchestration questions

How many AI coding agents should I run for a greenfield project?

Use as many as you can keep in view without losing control. OpenAI's harness case study ran effectively with 3 engineers driving a multiagent build over ~5 months and ~1,500 PRs, but they had strong internal tooling. If you don't have an orchestration layer, start with 3-5 workers plus one manager agent and scale up once you have a clear session-state view.

What's the safest way to use multi-agent orchestration for a legacy monolith?

Copy OpenAI's sandboxed migration pattern:

• Clone a sandbox per migration task.
• Run a single migration agent in that sandbox.
• Require tests and CI to pass before opening a PR.
• Release in strangler-style increments.

This keeps legacy risk contained while still letting agents do most of the refactoring and plumbing.

How do I keep agents from drifting off the brief on long-running tasks?

No tool today reliably auto-corrects drift. The current best practice is:

• Shorten task horizons (METR finds leading models can do ~2h17m of continuous work with ~50% correctness confidence METR, 2025).
• Add explicit checkpoint prompts ("summarize progress and planned next steps").
• Use an orchestrator seat to review summaries and redirect work when needed.

Maxxwell gives you a context-pressure readout with tiered warnings and a one-click compact, but it does not automatically re-aim or recycle context for you.

How does Maxxwell integrate with my existing Claude Code or OpenAI workflow?

At a minimum:

• You provide your own API keys or run existing CLI tools.
• Maxxwell starts each worker as a real terminal session using those tools.
• It tracks session state (working, idle, waiting_on_human, etc.) and exposes them in one window and via a CLI.

Because workers are unmodified, you can attach to any session directly and take over mid-sentence. The orchestrator seat is just another agent session, but wired to understand and control the fleet.

Where should I start integrating multi-agent orchestration in my team?

Based on DORA's finding that AI amplifies existing systems, the best entry points are:

• Greenfield internal tools where failure is cheap.
• Legacy migration slices with clean boundaries (reporting, analytics, non-critical modules).
• CI pipelines where agents can own tests, static analysis, and boilerplate refactors.

Use the patterns in the pillar article's sections on pipeline design and looping harnesses, then layer Maxxwell or a similar orchestration tool on top once multiple people are running agents concurrently.

Greenfield builds favor high autonomy and throughput, while legacy migrations prioritize risk containment with tighter scopes and more human review.

---