AI agent orchestration

by Ray Svitla

one AI agent is useful. two AI agents are twice the headache. five AI agents are a distributed systems problem wearing a trenchcoat.

agent orchestration is the art of making multiple agents work together without them duplicating effort, contradicting each other, or spiraling into infinite loops of polite disagreement. it’s harder than it sounds, and it sounds pretty hard.

the patterns

supervisor

one agent controls the others. it receives the task, breaks it into subtasks, assigns each to a specialized agent, collects results, and synthesizes the final output.

          ┌──────────┐
          │supervisor│
          └────┬─────┘
       ┌───────┼───────┐
       ▼       ▼       ▼
   ┌──────┐┌──────┐┌──────┐
   │coder ││tester││writer│
   └──────┘└──────┘└──────┘

the supervisor pattern is the most common because it’s the most understandable. one boss, multiple workers, clear chain of command. Claude Code’s sub-agent system (Task, Plan, Explore) works roughly this way — the main agent delegates specific subtasks.

when it works: well-defined tasks with clear decomposition. “build this feature” breaks into “write code,” “write tests,” “update docs.” each subtask is independent enough that agents don’t need to coordinate with each other, only with the supervisor.

when it breaks: tasks where subtasks are deeply interdependent. if the coder needs to know what the tester found, and the tester needs to know what the writer described, the supervisor becomes a bottleneck passing messages between agents who should just talk to each other.

hierarchical

supervisors all the way down. the top-level agent delegates to mid-level agents who delegate to specialized agents. like a corporate org chart, for better and worse.

              ┌────────┐
              │director│
              └───┬────┘
         ┌────────┼────────┐
         ▼        ▼        ▼
     ┌───────┐┌───────┐┌───────┐
     │backend││frontend││ infra │
     └───┬───┘└───┬───┘└───────┘
    ┌────┼────┐   │
    ▼    ▼    ▼   ▼
  ┌──┐┌──┐┌──┐┌──┐
  │db││api││ui││ux│
  └──┘└──┘└──┘└──┘

hierarchical orchestration handles complexity by distributing management. each mid-level agent understands its domain and makes local decisions without bothering the top-level agent.

the problem is the same problem as corporate hierarchies: information loss at each level. the director tells the backend lead to “optimize the API.” the backend lead tells the database agent to “improve query performance.” the database agent adds indexes everywhere. nobody asked whether the API bottleneck was actually in the database.

swarm

no central control. agents communicate peer-to-peer, picking up tasks based on their capabilities. think ant colony, not corporate hierarchy.

OpenAI’s Swarm framework popularized this pattern. agents have defined capabilities and handoff protocols. when an agent encounters something outside its expertise, it hands off to a more appropriate agent.

  ┌──────┐    ┌──────┐
  │agent1│◄──►│agent2│
  └──┬───┘    └───┬──┘
     │    ╲  ╱    │
     │     ╲╱     │
     │     ╱╲     │
     │    ╱  ╲    │
  ┌──┴───┐    ┌───┴──┐
  │agent3│◄──►│agent4│
  └──────┘    └──────┘

swarms are theoretically elegant and practically chaotic. without a supervisor, coordination emerges (or doesn’t) from local interactions. debugging a swarm is like debugging a distributed system — you can observe individual agents but the emergent behavior is hard to predict or control.

the honest assessment

most production agent systems use the supervisor pattern with light hierarchy. not because it’s the most elegant — it’s not — but because it’s the most debuggable. when something goes wrong, you can trace the decision chain: supervisor decided X, delegated to agent Y, agent Y produced Z.

swarms are interesting for research and genuinely useful for open-ended exploration tasks (web research, creative brainstorming). for anything where you need predictable, reliable output, centralized control wins.

the dirty secret: the best orchestration is often no orchestration. a single capable agent (Claude Code with good context engineering and a solid CLAUDE.md) outperforms a poorly-orchestrated multi-agent system on most tasks. adding agents adds complexity. complexity costs reliability.

when you actually need multiple agents

→ the task genuinely requires different capabilities (browsing + coding + data analysis) → the task is too large for one agent’s context window → you need parallelism — multiple independent subtasks running simultaneously → you need adversarial checking — one agent reviews another’s work

if your task doesn’t match any of these, a single agent with good tools is probably enough. the overhead of orchestration only pays off when single-agent limits are the actual bottleneck.

the patterns to watch

reflection loops — an agent does work, a critic agent reviews it, the original agent revises. simple, effective, and the basis for most quality-improvement patterns in production systems.

plan-then-execute — a planning agent creates a detailed plan, execution agents follow it. Claude Code’s /plan command is a lightweight version of this.

competitive agents — multiple agents attempt the same task independently, a judge agent picks the best result. expensive but effective for important decisions.

which pattern matches how you already work — and which one sounds like it would just add meetings?

→ agentic design patterns — broader pattern catalog → agent handoffs — the detail that breaks everything → agent failure modes — what goes wrong

Ray Svitla stay evolving