TL;DR — Static orchestration gives you predictability and lower cost; dynamic orchestration gives you adaptability. Most production systems end up hybrid — static for predictable workflows, dynamic only where measurements prove it’s worth the 15-25% token overhead.
Why Orchestration Is the Hard Problem
Every multi-agent system eventually hits the same fork in the road: should agent sequencing be predetermined at design time, or decided at runtime by an LLM? We’ve built production systems on both sides of this divide, and the honest answer is that neither approach is universally better. The right choice depends on how predictable your tasks are, how much you can afford to spend on routing tokens, and how badly you need to debug things when they break.
Static orchestration means the execution path is fixed before the first agent runs. A user request flows through Lead Agent to Worker A to Worker B to Output, every time, in that order. You get predictability, clean execution traces, and lower token costs. What you give up is adaptability — when a task doesn’t fit the predefined flow, the system either fails or produces suboptimal results.
Dynamic orchestration flips this: an orchestrator LLM evaluates each intermediate result and decides which agent to invoke next, continuing until the task is complete. This handles unexpected complexity gracefully and can route across specialists as needed. The trade-off is real, though — routing decisions consume tokens, execution paths become harder to predict, and debugging goes from “read the flow definition” to “reconstruct what the LLM was thinking.”
How the Major Frameworks Handle It
We’ve studied six major frameworks, and they all support both patterns. The question was never about capability — it’s about defaults and ergonomics.
The Claude Agent SDK takes a distinctive approach. For static flows, you define agents programmatically or through markdown files with explicit tool sets and model assignments. For dynamic work, the Task tool lets an orchestrator spawn sub-agents on demand, each running in its own isolated context window with native parallelization. The hooks system (PreToolUse, SubagentStop, PostToolUse) gives fine-grained control over agent behavior without requiring a full microservices architecture. In practice, the orchestrator-worker pattern with Claude Opus 4 delegating to Sonnet 4 sub-agents shows roughly 90% improvement on complex research tasks compared to a single agent.
OpenAI’s Agents SDK draws a clean line between code-driven chaining (where you explicitly sequence research_agent into outline_agent into writer_agent) and LLM-driven handoffs (where a coordinator agent with a list of specialists decides at runtime which one should handle a request). Both patterns are first-class citizens in the API.
LangGraph models everything as a graph. Static flows use sequential or parallel nodes with explicit edges. Dynamic routing uses conditional edge functions that inspect state and branch accordingly — you write a route_based_on_category function that maps classifier output to the appropriate specialist node.
CrewAI offers sequential processes for static work and a hierarchical mode where a manager agent delegates and validates. The hierarchical mode adds a manager LLM call for every delegation decision, which is worth knowing when you’re watching token costs.
AutoGen provides RoundRobin and Swarm patterns for predetermined flows, alongside SelectorGroupChat for dynamic agent selection. Google ADK follows a similar split: SequentialAgent and ParallelAgent for static work, LLM Transfer and AgentTool for dynamic delegation.
Our Data — The Claude Agent SDK’s orchestrator-worker pattern (Opus 4 delegating to Sonnet 4 sub-agents) shows roughly 90% improvement on complex research tasks compared to a single agent.
The Real Trade-offs
The static-versus-dynamic choice comes down to five dimensions, and they all pull in different directions.
Token cost is the most measurable. Dynamic orchestration adds 15-25% overhead for routing decisions alone. For simple, repetitive tasks, this overhead consistently exceeds the benefit. Latency follows a similar pattern — every routing decision adds a round-trip to the LLM before actual work begins.
Predictability and debuggability strongly favor static. When something fails in a static pipeline, you know exactly which agent produced the bad output and what its inputs were. In a dynamic system, you’re reconstructing the orchestrator’s reasoning chain, which may have involved multiple branching decisions that are hard to reproduce.
Adaptability is where dynamic earns its keep. Static flows fail silently on edge cases — the pipeline runs to completion but produces the wrong result because the task didn’t fit the predefined sequence. Dynamic orchestration can recognize when a task needs a different combination of specialists or more investigation than expected.
Error recovery is nuanced. Static systems need explicit error handling at each step. Dynamic systems can sometimes self-correct by routing to a different agent after a failure, but they can also enter infinite loops or stuck states without proper safeguards.
The Numbers — Dynamic orchestration adds 15-25% token overhead for routing decisions alone. For simple, repetitive tasks, this overhead consistently exceeds the benefit.
When Static Is the Right Call
Static orchestration works best when you can describe the workflow before it starts. Monitoring pipelines that run on a schedule, collect data, and produce reports are a natural fit — the steps never change, and you want the lowest possible cost per execution. PR review workflows follow a fixed checklist (lint, test, security scan, style review), so there’s no benefit to an LLM deciding what to check next. Issue-solving pipelines that move from issue analysis to solution implementation to PR creation are sequential by nature. Content production workflows with clear stage gates (brief, outline, draft, review) benefit from the shared context that a linear pipeline maintains.
LangChain’s own research confirms this: writing-intensive tasks and domains requiring shared context across steps consistently favor single or statically-orchestrated agents. The reason is simple — when every agent needs to understand what the previous one did, passing rich context through a fixed pipeline is cheaper and more reliable than having a coordinator summarize and re-explain at each routing decision.
When Dynamic Earns Its Cost
Dynamic orchestration justifies its overhead when you genuinely don’t know the execution path upfront. Complex research tasks where you might need two investigators or five, where one finding might invalidate a previous direction, are the clearest case. Academic research (arXiv:2505.19591) shows dynamic orchestration achieving superior performance with reduced computational costs specifically for complex problems where the path isn’t known upfront — the key qualifier being “complex.”
User-facing request routing is another strong fit. When someone asks “What’s my billing status?”, an LLM can classify the intent and hand off to the right specialist faster than you could maintain a rule-based router for every possible query. Multi-domain problems that require combining specialists from different areas benefit from a coordinator that understands which combination is needed. Exploration tasks with an unknown number of steps — security audits, root cause analysis, market research — are poorly served by fixed pipelines.
Building Hybrid Systems in Practice
We’ve found that most production systems end up hybrid, and the interesting question is where to draw the line. Our approach — detailed in our squads architecture — has been to start static and add dynamism only where we can measure the improvement.
Phase 1: Enhanced leads. The simplest hybrid takes your existing static lead agent and gives it conditional sub-agent spawning. The lead receives a request, analyzes the task type, spawns the appropriate workers, evaluates results, and decides whether it needs more workers or can synthesize a final output. This adds adaptability without full dynamic orchestration — the lead is still a single coordination point, but it can adjust based on what it encounters. The token overhead is modest (10-15%) because routing decisions are infrequent.
Phase 2: Router agents. For user-facing entry points, a dedicated router agent classifies incoming requests and dispatches to the appropriate squad. A request like “Help me understand our agent costs” might touch finance, engineering, and intelligence — the router evaluates which squad should own it and passes rich context for the handoff. Once routed, the receiving squad runs its normal static workflows. This adds 15-20% overhead but only at the entry point, not throughout the pipeline.
Phase 3: Full dynamic orchestration. RL-trained coordinators with learned routing require significant training data. We’d recommend deferring this until you have enough execution traces to train on — hundreds of diverse tasks with outcome labels, not dozens.
Handoff Protocols That Actually Work
Regardless of whether orchestration is static or dynamic, the quality of handoffs between agents determines system reliability. Effective handoffs depend heavily on context engineering. We’ve converged on structured handoff messages that include four things: a clear objective, explicit constraints (time limits, scope boundaries), the expected output format, and enough context summary that the receiving agent doesn’t need to reconstruct the full conversation history. The response should include a status, a result summary, artifact locations, and any follow-up items.
This protocol works identically for static and dynamic patterns. The only difference is who decides the next step — a fixed flow definition or an LLM evaluating the response.
Our Data — Enhanced leads add 10-15% token overhead; router agents add 15-20% but only at the entry point. Reserve full dynamic orchestration for when you have hundreds of diverse execution traces to train on.
Mistakes We’ve Seen (and Made)
The most expensive mistake is over-dynamism: using LLM routing for decisions that don’t require intelligence. If every task in your pipeline follows the same sequence, paying for a routing decision at each step is waste, not flexibility. We’ve seen systems where removing dynamic routing from predictable workflows cut token costs by 25% with no loss in output quality.
The opposite mistake — rigid static flows with no escape hatches — is subtler but equally costly. The pipeline completes successfully every time, but 10-15% of outputs are wrong because the task hit an edge case the pipeline wasn’t designed for. The fix isn’t full dynamism; it’s adding conditional branches for known variations while keeping the overall flow static.
Delegation without context is the third common failure mode. A router dispatches a request to a specialist with a one-line description, and the specialist lacks the information to do good work. Structured handoff protocols with explicit context summaries solve this, but they require discipline — it’s tempting to pass a task ID and assume the receiving agent can figure out the rest.
Two more patterns worth watching for: dynamic routing without fallbacks (which leads to infinite loops and stuck states — always set max iterations and timeouts) and shared context pollution, where all agents see all context from all other agents. Context windows fill up, agents get confused by irrelevant information, and costs balloon. Fresh context per worker with summaries for handoffs keeps things clean.
Key Takeaway — Removing dynamic routing from predictable workflows cut token costs by 25% with no loss in output quality. Over-dynamism is the most expensive mistake in agent orchestration.
Choosing Your Approach
The decision is simpler than it appears. If your workflow is predictable — and most workflows are — start with static orchestration. If you need adaptability at the entry point (user requests, varied task types), add a router. If individual workflows sometimes need to branch based on intermediate results, use enhanced leads. Reserve full dynamic orchestration for genuinely exploratory tasks where you can’t predict the number or type of steps.
Track four things to know if your choice is working: routing accuracy (are requests reaching the right agent?), handoff completion rate, token overhead from dynamic decisions, and escalation rate to humans. If routing accuracy drops below 90% or dynamic overhead exceeds 20% of total tokens, something in your architecture needs to change.
The hybrid approach works: static for predictable workflows, dynamic for unpredictable ones. Start simple, measure everything, and add complexity only when the measurements justify it.
Sources: Claude Agent SDK (Anthropic), OpenAI Agents SDK, LangGraph, CrewAI, AutoGen, Google ADK documentation. Academic: arXiv:2505.19591 (Multi-Agent Collaboration via Evolving Orchestration).
