How do parallel AI agents avoid merge conflicts?

The standard approach is git worktree isolation: each agent operates in its own worktree on a separate branch, working on non-overlapping files. The orchestration layer assigns tasks that touch different parts of the codebase. When agents finish, their branches are merged sequentially with automated conflict detection. If conflicts arise, a dedicated merge-resolution agent can handle them, or the orchestrator flags them for human review. Tools like amux track which files each agent is touching and warn before overlap occurs.

What is the difference between the five orchestration patterns?

Solo: one agent handles everything sequentially — simplest but slowest. Parallel Workers: multiple agents work on independent tasks simultaneously — fastest for embarrassingly parallel work. Pipeline: agents are arranged in stages (plan, implement, test, review) — best for quality-critical workflows. Hub-and-Spoke: a coordinator agent breaks down work and delegates to specialist agents — best for complex projects requiring architectural decisions. Swarm: agents self-organize via shared state (a task board or message bus) without a central coordinator — best for large-scale, loosely-coupled work.

How much does multi-agent orchestration cost?

Costs depend on the model, plan, and number of agents. With Claude Code Max ($100/month for Opus 4.6), running 5 parallel agents for 8 hours costs the subscription fee — no per-token charges. On API billing, the same workload costs roughly $30-80/day depending on task complexity and context window usage. A 10-agent fleet on API billing runs $50-150/day. The orchestration tools themselves are mostly free and open source (amux, Claude Squad, workmux). The main cost optimization lever is model routing: use cheaper models (Sonnet, Haiku) for routine tasks and reserve Opus for complex reasoning.

May 2026

AI Agent Orchestration in 2026: Patterns, Tools, and the Complete Architecture Guide

Q: How many AI coding agents can run in parallel?

On a modern laptop (16GB+ RAM), 5-7 terminal-based agents (Claude Code, Aider, Codex CLI) run comfortably. With 32GB+ RAM and git worktree isolation, 10-15 agents are practical. Cloud-hosted agents (Devin, Copilot Coding Agent, Codex cloud) have higher concurrency limits since compute is remote. Some teams report running 30-50+ agents on dedicated servers. The practical ceiling depends on your API rate limits (Anthropic's Claude Code Max allows ~45 Opus requests/5min), available memory, and disk I/O for git operations.

Multi-agent system inquiries surged 1,445% in 2025. Every major AI coding tool now supports some form of parallel agent execution. But running agents in parallel is not the same as orchestrating them. This guide covers the five proven orchestration patterns, the five-layer architecture stack that makes them work, every major orchestration tool compared, and the decision framework for choosing the right approach for your team and codebase.

1,445%

Surge in multi-agent system inquiries (2025)

Anthropic Agentic Coding Trends Report

5–7

Practical agent concurrency on a laptop (16GB RAM)

Empirical ceiling before perf degrades

3–8×

Throughput gain with orchestrated parallel agents

vs sequential single-agent workflow

Why orchestration — not just parallelism

Running five Claude Code sessions in five tmux panes is parallelism. It gives you raw throughput — five agents working simultaneously. But without orchestration, those agents will:

Edit the same files and create merge conflicts
Duplicate work because neither knows what the other is doing
Produce inconsistent APIs, naming conventions, and architectural patterns
Burn tokens re-reading context the other agent already processed
Silently fail with no monitoring or recovery

Orchestration is the infrastructure layer that turns raw parallelism into coordinated output. It handles five concerns that parallelism alone does not:

Orchestration = Parallelism + Isolation + Communication + Coordination + Observability. If you're missing any one of these, you have agents running in parallel — not an orchestrated system. The difference shows up in merge conflict rates, duplicated work, and the time you spend babysitting agents instead of reviewing their output.

The landscape has shifted dramatically. In January 2025, orchestration meant writing bash scripts around tmux send-keys. By May 2026, there are dedicated orchestration tools (amux, Claude Squad, workmux, Microsoft Conductor), and the major AI coding tools themselves are adding built-in multi-agent features: Cursor v3 with 8-agent parallelism, Google Antigravity 2.0 with Agent Teams, and GitHub Copilot’s multi-agent workspace.

The five orchestration patterns

Every multi-agent coding workflow maps to one of five patterns. These aren't theoretical — they're the patterns that emerged from teams actually running agent fleets in production. Understanding which pattern fits your work determines whether orchestration saves you time or creates overhead.

01 Solo Agent

Complexity: Trivial Agents: 1 Best for: focused tasks

One agent, one task, full context window. The baseline that every other pattern improves on. The solo agent sees everything, makes all decisions, and requires no coordination infrastructure.

Developer → [Agent] → Codebase Task → Agent reads context → Plans → Implements → Tests → PR

When to use: Tasks that fit within a single context window and touch fewer than ~15 files. Bug fixes, small features, refactors with clear scope. Any task where the overhead of splitting work exceeds the time saved by parallelism.

Tools: Claude Code, Cursor, Aider, Codex CLI, GitHub Copilot — any agent in its default single-session mode.

Ceiling: Throughput is capped at 1×. Complex tasks exhaust the context window. Can't parallelize independent subtasks.

02 Parallel Workers

Complexity: Low Agents: 2–50+ Best for: embarrassingly parallel work

Multiple agents work on completely independent tasks simultaneously. No inter-agent communication. Each agent operates in its own git worktree on a separate branch. Results are merged after all agents finish.

┌─ [Agent 1] → worktree-1/feature-auth Task Board → Dispatcher ─┼─ [Agent 2] → worktree-2/feature-search ├─ [Agent 3] → worktree-3/fix-pagination └─ [Agent 4] → worktree-4/refactor-api ↓ Sequential merge → main

The key requirement is task independence. If Agent 1's work touches files that Agent 3 also needs, you'll hit merge conflicts. The dispatcher (human or automated) must decompose work into non-overlapping file sets.

When to use: Sprint backlogs with independent tickets. Multi-service repos where each agent works on a different service. Test generation across independent modules. Bulk migrations (rename patterns, API version upgrades) that can be split by directory.

Tools: amux (task board + session management), Claude Squad (tmux session groups), workmux (git worktree + tmux), Microsoft Conductor (YAML-defined parallel tasks), DIY tmux + git worktrees.

Ceiling: Cannot handle tasks with shared dependencies. Merge phase can become a bottleneck. No quality gate between agents.

03 Pipeline

Complexity: Medium Agents: 3–6 per pipeline Best for: quality-critical workflows

Agents are arranged in sequential stages. Each stage's output becomes the next stage's input. The classic pipeline for production-quality code: plan → implement → test → review → merge. Different models or prompts can be used at each stage.

Spec → [Planner] → [Coder] → [Tester] → [Reviewer] → PR Opus 4.6 Sonnet 4.6 Sonnet 4.6 Opus 4.6 (architect) (implement) (write tests) (find bugs) Gate: plan Gate: code Gate: tests Gate: review approved? compiles? pass? approved?

Each stage has a quality gate — the next agent only starts if the previous stage's output meets criteria (tests pass, lint clean, review approved). This catches errors early instead of discovering them after the full workflow completes.

When to use: Features that require architectural planning before implementation. Security-sensitive code that needs multi-layer review. Regulated environments where audit trails matter. Any workflow where you'd assign the task to different people with different roles.

Tools: amux (board-based stage tracking), Microsoft Conductor (YAML pipeline definitions), Kiro (spec-driven agents with built-in planning stages), custom scripts using Claude Code headless mode.

Ceiling: Latency scales linearly with stages. A slow stage bottlenecks the whole pipeline. Higher total token cost than parallel workers (each stage builds on full prior context).

04 Hub and Spoke

Complexity: Medium-High Agents: 1 hub + 3–10 spokes Best for: complex projects with dependencies

A coordinator agent (the hub) analyzes the task, creates a plan, decomposes it into subtasks, and delegates to specialist agents (the spokes). The hub monitors progress, resolves conflicts, and integrates results. Think of it as a tech lead directing a team.

┌─ [Frontend Agent] → React components │ Feature Spec → [Coordinator] ─┼─ [Backend Agent] → API endpoints (Opus 4.6) │ ├─ [Test Agent] → Integration tests │ └─ [Docs Agent] → API documentation ↑ Coordinator reviews, resolves conflicts, merges branches, verifies integration

The coordinator agent typically runs a more powerful model (Claude Opus 4.6) for planning and review, while spoke agents use faster, cheaper models (Claude Sonnet 4.6) for implementation. The coordinator maintains the architectural vision across all agents.

When to use: Full-stack features requiring coordinated frontend, backend, and test changes. Large refactors where an architect needs to maintain consistency. Greenfield projects where structure needs to be established before agents start coding. Any task where the decomposition itself requires intelligence.

Tools: amux (coordinator creates board tasks, spokes claim them), Google Antigravity 2.0 Agent Teams (built-in hub-spoke), Cursor v3 multi-agent (coordinator manages up to 8 agents), Claude Code subagents (parent spawns child agents).

Ceiling: The coordinator is a single point of failure. If it misdecomposes the task, all spokes produce wrong output. Higher coordination overhead. Coordinator context window limits the number of active spokes it can track.

05 Swarm

Complexity: High Agents: 5–50+ Best for: large-scale, loosely-coupled work

No central coordinator. Agents self-organize by reading from and writing to shared state — a task board, a message bus, or a shared filesystem. Each agent autonomously picks up work, completes it, and posts results. Other agents react to those results. Emergent coordination replaces centralized planning.

[Agent 1] ←──→ ┌──────────────────┐ ←──→ [Agent 4] │ │ [Agent 2] ←──→ │ Shared State │ ←──→ [Agent 5] │ (Task Board + │ [Agent 3] ←──→ │ Message Bus) │ ←──→ [Agent 6] └──────────────────┘ ↑ Agents claim tasks atomically, post results, discover new work

The swarm pattern requires atomic task claiming (so two agents don't grab the same task), idempotent operations (so retries don't corrupt state), and convergence detection (so the system knows when all work is done). It scales better than hub-and-spoke because there's no coordinator bottleneck, but it's harder to debug when things go wrong.

When to use: Large-scale migrations affecting hundreds of files. Test suite generation across an entire codebase. Codebase-wide lint fixes or dependency upgrades. Continuous improvement loops where agents create work for each other (one agent finds bugs, another fixes them).

Tools: amux (board with atomic claiming + session-to-session messaging), LangGraph (graph-based agent coordination), AutoGen (multi-agent conversation framework), custom implementations using shared SQLite or Redis.

Ceiling: Hardest pattern to debug. Emergent behavior can be unpredictable. Requires robust shared-state infrastructure. Risk of agents creating circular work (Agent A creates task, Agent B processes it, result triggers Agent A again).

Pattern comparison matrix

Pattern	Agents	Throughput	Quality Control	Complexity	Coordination Overhead	Best Codebase Size
Solo Agent	1	1×	None (agent self-reviews)	Trivial	Zero	Any
Parallel Workers	2–50+	N× (linear)	Post-hoc review	Low	Task decomposition only	Multi-service, modular
Pipeline	3–6	1× per pipeline	Stage gates	Medium	Gate definitions	Any (quality focus)
Hub & Spoke	4–11	N× (with overhead)	Coordinator review	Medium-High	Coordinator capacity	Full-stack, cross-cutting
Swarm	5–50+	N× (near-linear)	Peer review / gates	High	Shared state infra	Large, loosely-coupled

Most teams combine patterns. A typical production setup uses Parallel Workers for independent tickets, Pipelines for quality-critical features, and Hub-and-Spoke when a coordinator needs to maintain architectural consistency. Start with Parallel Workers — it has the best effort-to-throughput ratio.

The five-layer orchestration stack

Every orchestration pattern relies on the same five infrastructure layers. Understanding these layers helps you evaluate tools (which layers does each tool cover?) and identify gaps in your own setup.

┌─────────────────────────────────────────────────────────┐ │ Layer 5: Observability │ │ Monitoring, cost tracking, health checks, dashboards │ ├─────────────────────────────────────────────────────────┤ │ Layer 4: Coordination │ │ Task boards, atomic claiming, conflict resolution │ ├─────────────────────────────────────────────────────────┤ │ Layer 3: Communication │ │ REST APIs, MCP, shared filesystem, message passing │ ├─────────────────────────────────────────────────────────┤ │ Layer 2: Isolation │ │ Git worktrees, branches, containers, sandboxes │ ├─────────────────────────────────────────────────────────┤ │ Layer 1: Runtime │ │ tmux, terminal sessions, containers, cloud VMs │ └─────────────────────────────────────────────────────────┘

L1 Runtime

Where agents physically execute. On a single machine, this is typically tmux sessions — each agent runs in its own tmux pane with its own shell, environment, and working directory. amux manages these sessions automatically. For cloud-hosted agents, the runtime is a container or VM: Devin runs in dedicated cloud sandboxes, GitHub Copilot Coding Agent runs in GitHub Actions runners, and OpenAI Codex cloud tasks run in isolated containers.

The runtime layer handles process lifecycle: starting agents, restarting them when they crash or exhaust their context window, and cleanly shutting them down when work is complete.

L2 Isolation

How you prevent agents from interfering with each other. The standard approach is git worktrees: each agent gets its own working copy of the repo on its own branch. Changes are isolated until explicitly merged. This is cheaper than containers (no VM overhead) and provides natural conflict detection via git.

For stronger isolation (untrusted code execution, network restrictions), tools like E2B, Docker, and gVisor provide container-level sandboxing. Claude Code offers built-in permission controls (allowlist/denylist for tools, file paths, and network access) as a lightweight alternative.

L3 Communication

How agents exchange information. Four approaches, in increasing sophistication:

Shared filesystem: Agents read/write shared files (a spec doc, a TODO list, a results file). Simple but prone to race conditions.
REST APIs: Agents communicate via HTTP endpoints. amux provides this natively — agents can peek at each other's output, send messages, and read/write to a shared board via curl.
MCP (Model Context Protocol): Anthropic’s open protocol for giving agents structured access to tools and data sources. Agents can share MCP servers to access the same databases, APIs, and services.
A2A (Agent-to-Agent Protocol): Google’s protocol specifically designed for inter-agent communication. Still early but gaining adoption in enterprise multi-agent deployments.

L4 Coordination

How work is assigned, tracked, and conflict-resolved. The core primitive is a task board with atomic claiming — an agent claims a task in a single operation that prevents any other agent from claiming the same task simultaneously. amux's SQLite-backed kanban board provides this natively. Microsoft Conductor uses YAML workflow definitions. DIY setups often use Redis or Postgres advisory locks.

Coordination also includes merge conflict resolution. When two agents' branches conflict, the orchestrator can: (a) re-run one agent on top of the other's changes, (b) spawn a dedicated merge-resolution agent, or (c) flag the conflict for human review.

L5 Observability

Knowing what your agents are doing, how much they're spending, and whether they're stuck. This includes: real-time session output monitoring, per-agent token cost tracking, health checks (is the agent responsive? has it been idle for too long?), and dashboards that show fleet status at a glance.

amux provides a web dashboard accessible from any device (including a mobile app) with live session output, token spend graphs, and board status. For custom monitoring, agents can write structured logs that feed into Grafana, Datadog, or any observability platform.

Tool landscape: 12 orchestrators compared

The orchestration tool landscape splits into three tiers: dedicated orchestrators (purpose-built for multi-agent coordination), built-in multi-agent features (part of a larger AI coding tool), and agent frameworks (general-purpose multi-agent SDKs you can build orchestration on top of).

Dedicated orchestrators

amux

Open Source Python All 5 layers

Full-stack agent control plane: tmux session management, SQLite task board with atomic claiming, inter-agent REST API, git worktree isolation, token spend tracking, web dashboard (desktop + mobile PWA), self-healing watchdog, and cron scheduler. Single-file Python server. Works with any terminal-based agent (Claude Code, Aider, Codex CLI, Goose). Supports all five patterns. Covers layers 1–5.

Claude Squad

Open Source Go Layers 1–2

TUI for managing multiple AI coding agents in tmux sessions. Handles session lifecycle and git worktree isolation with a clean terminal interface. Supports Claude Code, Aider, Codex CLI, and other terminal agents. Focused on the runtime and isolation layers — you provide your own coordination and observability. Covers layers 1–2.

workmux

Open Source Rust Layers 1–2

Git worktree + terminal multiplexer automation. Manages worktree creation, branch tracking, and terminal session layout for parallel development. Works with tmux, Zellij, and Kitty. Lightweight, focused on the mechanical layer of worktree + session management. Covers layers 1–2.

Microsoft Conductor

Open Source TypeScript Layers 3–4

CLI for defining multi-agent workflows in YAML. Declarative pipeline and parallel task definitions. Supports GitHub Copilot SDK and Anthropic Claude agents. Strong on coordination and communication layers but delegates runtime and isolation to the underlying tools. Covers layers 3–4.

Built-in multi-agent features

Cursor v3 Multi-Agent

Commercial $20–200/mo Built-in

Run up to 8 agents in parallel within the Cursor IDE. Agents share context and can be assigned different tasks. Background agents can continue working while you switch to other tasks. Local-to-cloud handoff for longer-running work. Covers layers 1–4 within the Cursor ecosystem.

Google Antigravity 2.0 Agent Teams

Commercial $20–200/mo Built-in

Agent Teams panel in the Antigravity IDE. Visual orchestration of multiple agents with a built-in browser for verification. Voice commands via Gemini Audio models. Managed Agents API for programmatic orchestration. Runs on Gemini 3.5 Flash with 1M-token context. Covers layers 1–5 within the Antigravity ecosystem.

Claude Code Subagents

$20–200/mo Built-in

Claude Code can spawn subagents within a single session — child agents that work on focused subtasks and report back to the parent. Subagents share the parent's permission settings but have isolated context windows. Useful for Hub-and-Spoke within a single session. For true multi-session orchestration, pair with amux or Claude Squad. Covers layers 1–2 for single-session use.

Devin

$500/mo Built-in

Fully autonomous cloud agent by Cognition. Runs in a cloud sandbox with its own shell, browser, and editor. Can spawn multiple parallel tasks. The most expensive option but requires zero local infrastructure. Best for teams that want a hands-off, cloud-hosted approach. Covers all 5 layers in a managed cloud environment.

Agent frameworks (build-your-own orchestration)

LangGraph

Open Source Python / JS

Graph-based multi-agent orchestration framework by LangChain. Define agent workflows as directed graphs with nodes (agents) and edges (transitions). Strong support for cycles, conditional routing, and persistent state. Good for building custom Pipeline and Hub-and-Spoke patterns. Requires significant custom code for coding-specific orchestration.

CrewAI

Open Source Python

Role-based multi-agent framework. Define agents with roles, goals, and backstories, then assign them to tasks. Built-in sequential and parallel task execution. Simpler API than LangGraph. Better for non-coding multi-agent workflows (research, analysis) than for code orchestration, but can be adapted.

AutoGen

Open Source Python

Multi-agent conversation framework by Microsoft. Agents interact via message-passing conversations. Strong support for human-in-the-loop patterns. The most research-oriented of the three frameworks — more papers published with AutoGen than any other multi-agent framework. Good for Swarm patterns where agents need to negotiate and iterate.

Mastra

Open Source TypeScript

TypeScript-native AI agent framework from the team behind Gatsby. First-class TypeScript support, built-in tool use, and workflow orchestration. Good choice for teams already in the TypeScript ecosystem that want to build custom orchestration logic.

Feature matrix

Tool	Type	License	Runtime (L1)	Isolation (L2)	Communication (L3)	Coordination (L4)	Observability (L5)	Patterns Supported
amux	Orchestrator	MIT	✓	✓	✓	✓	✓	All 5
Claude Squad	Orchestrator	MIT	✓	✓	✗	✗	Partial	Parallel, Solo
workmux	Orchestrator	MIT	✓	✓	✗	✗	✗	Parallel, Solo
Conductor	Orchestrator	MIT	Partial	✗	✓	✓	Partial	Parallel, Pipeline
Cursor v3	Built-in	Commercial	✓	✓	✓	✓	Partial	Parallel, Hub&Spoke
Antigravity 2.0	Built-in	Commercial	✓	✓	✓	✓	✓	All 5
Claude Code	Built-in	Commercial	✓	✓	Subagents	✗	✗	Solo, Hub&Spoke
Devin	Built-in	Commercial	✓	✓	✓	✓	✓	All 5
LangGraph	Framework	MIT	✗	✗	✓	✓	Partial	Pipeline, Hub&Spoke, Swarm
CrewAI	Framework	MIT	✗	✗	✓	✓	Partial	Pipeline, Hub&Spoke
AutoGen	Framework	MIT	✗	✗	✓	✓	Partial	Swarm, Hub&Spoke
Mastra	Framework	MIT	✗	✗	✓	✓	✗	Pipeline, Parallel

Dedicated orchestrators vs. built-in features: Built-in multi-agent features (Cursor, Antigravity) lock you into one coding tool. Dedicated orchestrators (amux, Claude Squad) work with any terminal-based agent and let you mix tools — run Claude Code on Opus for architecture, Aider with DeepSeek for bulk refactors, and Codex CLI for OpenAI-specific tasks — all in one fleet.

Production concerns: cost, safety, and scaling

Cost management

Multi-agent orchestration multiplies both throughput and cost. A solo agent running Claude Opus 4.6 on a complex task might consume 500K–2M tokens. Five parallel agents doing similar work consume 5× that. Cost management strategies:

Model routing: Use Opus for planning, architecture, and code review. Use Sonnet for implementation and tests. Use Haiku for lint fixes, formatting, and simple migrations. A typical fleet saves 40–60% by routing tasks to the cheapest model that can handle them.
Context discipline: Agents with smaller, focused context windows use fewer tokens per request. A well-scoped task description with clear file boundaries keeps agents from exploring the entire codebase.
Max plan economics: Anthropic’s Claude Code Max plan ($100–200/month) removes per-token billing. If you're running 3+ agents regularly, the flat rate is almost always cheaper than API billing.
Per-agent cost tracking: amux tracks token spend per session so you can identify which agents are consuming disproportionate resources and optimize their prompts or scope.

Safety guardrails

Multiple agents amplify both output and risk. A single mis-configured agent can cause damage — a fleet of them can do it five times faster.

Non-negotiable guardrails for multi-agent setups:

Git isolation: Every agent must work on its own branch (preferably in its own worktree). Never let two agents edit the same branch.
No force-push: Agents should never git push --force or git reset --hard on shared branches.
Secrets isolation: Use Claude Code hooks or tool permissions to prevent agents from reading .env files, credentials, or secret stores.
Network restrictions: Agents that don't need network access shouldn't have it. Block outbound requests except to approved domains.
Human review before merge: No agent output should merge to main without human review. Automated CI gates (tests, lint, type check) are necessary but not sufficient.

For a comprehensive safety framework, see our AI Coding Agent Safety Checklist.

Scaling considerations

Scale	Agents	Infrastructure	Bottleneck	Recommended Pattern
Solo	1–2	Single terminal	Context window	Solo or Pipeline
Small fleet	3–7	tmux + git worktrees	API rate limits	Parallel Workers
Medium fleet	8–20	Orchestrator + worktrees	Disk I/O, merge conflicts	Hub & Spoke
Large fleet	20–50+	Orchestrator + cloud agents	Coordination overhead	Swarm

Key scaling limits:

RAM: Each Claude Code session uses ~200–400MB. On 16GB RAM, 5–7 agents are comfortable. On 32GB+, 15–20 agents work before you start swapping.
API rate limits: Anthropic’s Max plan allows ~45 Opus requests per 5-minute window. More agents means more queueing and backoff.
Disk: Each git worktree is a full working copy. For large repos (10GB+), 20 worktrees consume 200GB+ of disk. Use shallow clones or sparse checkout to reduce per-worktree size.
Merge queue: The more agents, the longer the sequential merge phase. At 20+ agents, automated merge resolution becomes essential.

Decision framework

Choosing an orchestration pattern and tool depends on your team size, codebase structure, and what you're trying to accomplish.

Solo developer, focused tasks

Pattern: Solo Agent or Parallel Workers (2–3 agents)
Tool: Claude Code with subagents, or amux for quick parallel sessions
Why: Minimal overhead. No coordination infrastructure needed. The agent handles everything within its context window. Scale to 2–3 workers when you have independent tickets.

Solo developer, ambitious throughput

Pattern: Parallel Workers (5–10 agents) with Pipeline for critical features
Tool: amux (task board + monitoring) or Claude Squad (lighter, TUI-focused)
Why: You're the bottleneck on decomposition and review, not the agents. The orchestrator handles session management and isolation so you focus on specs and review.

Small team (2–5 developers)

Pattern: Hub and Spoke (coordinator agent plans, workers implement)
Tool: amux (shared board for team visibility) or Cursor v3 (if team is IDE-centric)
Why: Multiple people are creating tasks for agents. A shared board provides visibility into who's running what. The coordinator pattern ensures architectural consistency across agents spawned by different team members.

Enterprise or large codebase (100K+ lines)

Pattern: Swarm with quality gates
Tool: amux (atomic claiming + full observability), Devin (managed cloud agents), or Microsoft Conductor (enterprise workflow definitions)
Why: At scale, centralized coordination becomes a bottleneck. Swarm patterns with atomic task claiming let agents self-organize. Quality gates (CI checks, automated review) replace the human coordinator.

Cloud-first, hands-off

Pattern: Depends on task — Devin handles its own orchestration internally
Tool: Devin or GitHub Copilot Coding Agent
Why: Zero local infrastructure. Agents run in cloud sandboxes. You interact via PRs and Slack messages. Higher cost ($500+/month) but zero ops burden.

Anti-patterns: when NOT to orchestrate

Orchestration has overhead. Not every task benefits from it. Avoid these common traps:

Orchestration anti-patterns:

Premature orchestration: Spinning up 5 agents for a task that one agent could finish in 10 minutes. The decomposition and merge overhead exceeds the time saved.
Over-splitting: Breaking a feature into such fine-grained tasks that agents lack enough context to make good decisions. Each agent sees a sliver and produces code that doesn't integrate cleanly.
No review bottleneck planning: Running 10 agents overnight when you can only review 3 PRs in the morning. The unreviewed branches create a backlog that grows stale and conflicts with newer work.
Tightly-coupled codebase: If every feature touches the same 5 files (common in monoliths with a fat utils.py or types.ts), parallel agents will constantly conflict. Refactor the coupling first.
Ignoring coordination costs: Each additional agent adds merge, review, and conflict-resolution overhead. The throughput curve flattens above 7–10 agents unless your codebase is highly modular.

The rule of 3: If a task can be decomposed into 3+ independent, non-overlapping subtasks that each take 15+ minutes for a solo agent, orchestrate. Below that threshold, a single agent with subagents is usually faster end-to-end.

Frequently asked questions

What is AI agent orchestration?

AI agent orchestration is the practice of coordinating multiple AI coding agents working in parallel on a shared codebase. It includes task assignment, code isolation (via git worktrees), inter-agent communication, conflict resolution, and observability. Tools like amux, Claude Squad, and Microsoft Conductor provide orchestration infrastructure.

How many AI coding agents can run in parallel?

On 16GB RAM: 5–7 agents comfortably. On 32GB+: 10–15 agents. With cloud agents (Devin, Copilot Coding Agent), concurrency is higher since compute is remote. The practical ceiling depends on API rate limits, memory, and disk I/O.

How do you prevent merge conflicts with parallel agents?

Three techniques: (1) File-level task decomposition — assign agents to non-overlapping file sets. (2) Git worktree isolation — each agent works in its own worktree on its own branch. (3) Sequential merge with conflict detection — merge branches one at a time, with automated conflict resolution or human review for conflicts.

What is the cheapest way to run multi-agent orchestration?

Use open-source orchestrators (amux, Claude Squad, workmux) with Anthropic’s Claude Code Max plan ($100/month flat rate) or API-based billing with aggressive model routing (Haiku/Sonnet for routine tasks, Opus only for complex reasoning). A well-optimized 5-agent fleet can run for under $150/month.

Should I use a dedicated orchestrator or a built-in multi-agent feature?

Dedicated orchestrators (amux) are tool-agnostic — you can mix Claude Code, Aider, Codex CLI, and others in one fleet. Built-in features (Cursor multi-agent, Antigravity Agent Teams) offer tighter integration but lock you into one ecosystem. Choose dedicated if you want flexibility; choose built-in if you want simplicity and are already committed to one tool.

What is the difference between orchestration and an agent framework?

Agent frameworks (LangGraph, CrewAI, AutoGen) provide primitives for building multi-agent systems: message passing, state management, graph routing. Orchestrators (amux, Claude Squad) are ready-to-use tools that handle the full stack: session management, git isolation, task boards, monitoring, and fleet operations. Frameworks require custom code; orchestrators work out of the box.

Ready to orchestrate your first agent fleet?

amux is a free, open-source agent control plane that supports all five orchestration patterns. Install in 30 seconds, run your first parallel agents in under 5 minutes.

Get started View on GitHub