Agent orchestration is a control layer, not a framework

Agent orchestration, defined

The load-bearing word is layer. The orchestrator is not the agent and not the model. It is the thing that outlives any single call: it knows what has already run, what the run is allowed to cost, and what happens when step 4 of 9 throws a 429. Take that layer away and you do not have a simpler agent. You have a loop with no brakes.

Where the word came from

Orchestration was borrowed twice before it reached agents.

First from web services. WS-BPEL 2.0 became an OASIS Standard in April 2007 and described this exact shape: one central process that calls out to services, holds the state of the conversation, and defines fault and compensation handling. Then from infrastructure, where Kubernetes shipped under the banner "production-grade container orchestration" and Apache Airflow — Apache Incubator in 2016, top-level project in 2019 — made DAGs, retries and backfills standard vocabulary for data teams. Same claim both times. The coordinator is not the worker.

The agent sense dates to AutoGPT, spring 2023. AutoGPT had no coordinator: one model, one loop, and the loop decided when to stop — which is why it so often did not. Everything after it was a correction. OpenAI published Swarm in late 2024 as an explicitly educational "lightweight multi-agent orchestration" framework, then replaced it with the Agents SDK in March 2025. The SDK's four named primitives are agents, handoffs, guardrails and sessions. Routing, delegation, limits, state. That list is the definition of the field.

What it is not

Two different things get called orchestration

Anthropic's December 2024 piece draws the line most people are actually arguing about: workflows are systems where LLMs and tools are orchestrated through predefined code paths, and agents are systems where LLMs dynamically direct their own processes and tool usage. Both get called orchestration. Label them.

Type 1 — control-plane orchestration. Deterministic code owns the graph. The model is one step inside it. Temporal, AWS Step Functions, LangGraph. Properties: resumable after process death, replayable from a log, retry policy expressed in config rather than English.

Type 2 — model-directed orchestration. A lead model picks the next hop. OpenAI handoffs, AutoGen group chat, CrewAI's hierarchical process. Properties: handles branches you did not anticipate, and is not replayable unless you recorded every decision.

Build both. A Type 1 skeleton with Type 2 reasoning inside a bounded node is the only arrangement that survives contact with production: pure Type 1 snaps on the first branch nobody anticipated, and pure Type 2 cannot be debugged after the fact because there is nothing to replay.

There is also a third, unrelated homonym: in martech, "orchestration" means cross-channel campaign sequencing. I spent a decade in that world building Metadata.io, and the overlap with agent orchestration is the word only. If someone says orchestration and you cannot tell which of the three they mean, ask before you agree to anything.

A worked example with published numbers

Anthropic's research system, documented June 2025, is the clearest public example because the specifics are on the record. A lead agent (Claude Opus 4) receives a query, writes a plan to memory, and spawns subagents (Claude Sonnet 4) that run in parallel, each with its own context window. Results come back to the lead, which decides whether to spawn more. A separate citation agent attributes claims at the end.

The orchestration lives in the prompt rules and the plumbing, not the model. Effort scaling is specified explicitly:

The plan is written to memory so a run that exceeds the 200,000-token context window does not restart from zero. The payoff is measured: the multi-agent system outperformed single-agent Claude Opus 4 by 90.2% on their internal research eval. So is the bill. Agents use roughly 4x the tokens of chat, multi-agent systems roughly 15x, and token usage, tool calls and model choice explained about 80% of the performance variance.

That 15x is the honest cost of orchestration. It is why I will not point a fan-out architecture at a task a single capped agent can finish — the extra subagents buy you breadth you did not need and a token bill you cannot defend. Capping one agent properly beats orchestrating five badly.

Five tests for whether it qualifies

1. Point at the decider. Name the component that chooses the next step. If it is the same component doing the work, you have an agent, not orchestration.
2. Kill the process mid-run. Does it resume from step 6, or start again at step 1? Resumption is the whole argument for a durable engine like Temporal.
3. Find the step cap. If the only limit is a sentence in the system prompt, there is no limit. Unbounded loops are the most common production failure in agent systems, and the fix is a counter enforced in code outside the model.
4. Try to replay a run. No replay means no debugging, which means every incident is a guess.
5. Run two things at once. Can it fan out, and does the join actually wait for stragglers rather than returning partial results silently?

Score three or fewer and what you have is a prompt chain with ambitions — which is fine, as long as nobody is calling it infrastructure.