A single agent with a handful of tools can handle many AI features. When it needs help, the next decision is how to divide the work. Application code can assign each step, a lead agent can delegate subtasks, or specialists can transfer responsibility between themselves.
These six orchestration patterns differ in how they share context, choose the next step, and recover from failure. Choose a pattern that addresses a specific limitation in your workload, then measure whether the added coordination improves the result.
Copy link to headingWhat is agent orchestration?
Agent orchestration determines how agents divide a task and pass work between themselves. It decides which agent runs next, what information that agent receives, how agents return results, and when execution stops.
A single agent calling tools in a loop is the starting point. A multi-agent system adds specialists with their own instructions, tools, and context windows. The orchestrator must give each specialist enough information to do their work without copying every intermediate result into every context.
Code-driven orchestration uses application rules to choose the next step. Those rules can branch, repeat work, or inspect intermediate results. Model-driven orchestration lets a model choose the next step by planning, selecting tools, or delegating.
A system can use both approaches. A model might choose the specialist for an ambiguous support request, while code requires a policy check before that specialist issues a refund.
Copy link to headingWhat changes when more agents participate?
Additional agents consume tokens to receive instructions, process context, and report results. Anthropic reported approximately 4× token usage for agents and 15× for multi-agent systems relative to chat interactions in its research-system measurements.
Errors can also propagate. If ten required steps succeed independently with 95% probability each, overall success is about 60%. At 90% per step, it is about 35%. Validation and recovery change those assumptions, so the calculation illustrates the risk of an unchecked sequence rather than predicting every workflow.
Failures become more expensive when completed work exists only in memory. A worker can finish a task, then lose its result when the caller crashes before recording it. Recovery may repeat the model call and its cost.
Debugging also requires more than an individual request log. Use session-level agent traces to connect routing decisions, worker calls, tool executions, and approval outcomes. These records show what the system did, without claiming to expose the model's internal reasoning.
Code-driven routing makes execution easier to inspect, but it does not provide persistence or prevent error propagation on its own.
Copy link to headingSix agent orchestration patterns
Copy link to headingSequential orchestration
Sequential orchestration runs agents in a predefined order. Each stage processes the previous stage's output, as in a support reply that moves through drafting, review, and formatting. The pattern is also called prompt chaining or a pipeline.
Application code defines the sequence. Validation gates can stop invalid output before it reaches the next agent, and the number of stages helps estimate cost. Actual token usage still varies with input length, output length, and retries.
Use this pattern when the stages and their dependencies are known. Backtracking or dynamic routing requires additional control flow, at which point the system no longer follows a strictly linear pipeline.
Copy link to headingConcurrent orchestration
A code change can undergo security, performance, and style reviews at the same time. Concurrent orchestration assigns those independent tasks to agents, then combines their findings. It is also called parallelization, fan-out/fan-in, or scatter-gather.
Branches may inspect the same input or separate portions of a larger task. The dispatcher chooses which branches run, using fixed rules or model judgment.
Parallel execution reduces latency when branches do not depend on each other. It also adds model calls and a merge step. Decide how that step handles disagreement, missing results, and branch failures before increasing concurrency.
Copy link to headingOrchestrator-worker orchestration
In orchestrator-worker orchestration, one lead agent divides a task into subtasks at runtime, delegates them, and combines the results. This is also called a centralized or single-orchestrator pattern.
A research agent might assign different parts of a question to workers. Each worker explores its assigned area in a separate context window and returns a focused result.
The lead owns the final answer, but every returned result adds to its context. Workers should return the information needed for synthesis, with references to the underlying material when the lead needs to inspect it.
Use this pattern when you need to identify subtasks during execution and one agent should remain responsible for the answer. A planning variant, sometimes called magentic orchestration, maintains a task ledger and revises the plan as work progresses.
Copy link to headingHierarchical orchestration
Hierarchical orchestration adds supervisors between the lead agent and its workers. A coding system might assign backend changes, frontend changes, and tests to separate supervisors, each of which manages its own team.
This reduces the detail each supervisor must handle. It also adds delegation and synthesis at every level. When a supervisor summarizes a worker's result, it can omit information that the next level needs.
Keep original outputs in persistent agent memory so later steps can retrieve details that summaries leave out. Add another supervisor only when it addresses a demonstrated context or coordination problem.
Copy link to headingHandoff orchestration
A support agent may discover that a request belongs with billing rather than technical support. Handoff orchestration lets it transfer control and the required context to the billing specialist.
The receiving agent becomes responsible for continuing the conversation or task. This differs from an orchestrator invoking a worker and waiting for its result.
A transfer loses context when it omits required history, tool results, permissions, or task state. Define what each handoff must include, cap the number of transfers, and specify what happens when no specialist can complete the request.
If the destination follows a known rule, the application code can dispatch the request directly. Autonomous agents do not need to negotiate every routing decision.
Copy link to headingGroup chat orchestration
Group chat orchestration lets agents contribute to a shared conversation. A manager or turn-selection policy chooses who responds next and when the discussion ends.
A maker-checker loop is one form. The maker drafts a response, the checker evaluates it against explicit criteria, and the maker revises it. This is also called evaluator-optimizer orchestration.
The shared conversation records how the output developed, but the discussion can continue without improving it. Set a round limit. If the agents still cannot produce an acceptable result, send it to a human reviewer, return it with a warning, or stop the run with an error.
A related approach, the blackboard pattern, uses a common board for requests and contributions. One implementation reported 13% to 57% relative improvements in end-to-end success over strong baselines across KramaBench and modified versions of DSBench and DA-Code. That result applies to the evaluated data-discovery tasks.
Copy link to headingBuilding reliable agent orchestration
Copy link to headingTest a single agent before adding more
Start with the limitation. Does the agent lack context space? Does it select the wrong tools? Does the task contain independent work that could run in parallel? Do different operations need separate permissions?
Adding agents without answering those questions introduces coordination cost without a clear reason to expect better results.
A study using equal thinking-token budgets found that single agents matched or outperformed the tested multi-agent systems on multi-hop reasoning across Qwen3, DeepSeek-R1-Distill-Llama, and Gemini 2.5. The finding supports comparing architectures with similar budgets, while leaving open which architecture performs best on other tasks.
Reducing complexity can also improve a single agent. Vercel reported that removing 80% of d0's tools made its internal data agent 3.5× faster, reduced token usage by 37%, and increased success from 80% to 100% across five representative benchmark queries.
Copy link to headingKeep required sequences in code
If every refund requires a policy check before payment, enforce that dependency in code. If retrieval requires validated input, make validation a prerequisite.
Reserve model judgment for decisions that depend on ambiguous content or discoveries made during execution. A vague support request may need interpretation; a required authorization check does not.
Put schema and policy checks between agents to reject invalid intermediate output before another agent acts on it. A valid schema confirms structure, so factual claims and business permissions still need their own checks.
Copy link to headingLimit repeated work and total spending
Model-controlled tool loops, maker-checker cycles, and repeated handoffs need limits outside the model.
In AI SDK 7, ToolLoopAgent stops after 20 steps by default. WorkflowAgent.stream() has no default step limit, while WorkflowAgent.generate() defaults to 20 steps. Set stopWhen explicitly when the application needs a specific limit.
Set limits for each agent and the complete run. A parent agent's step limit does not replace limits on its workers. Cap handoffs, bound parallelism, and track token usage or spending across all calls.
Define what happens when a limit is reached. The system might return a partial result, ask for human input, or stop with an error. Reaching a limit should not silently count as successful completion.
Copy link to headingPersist completed work and protect against duplicate actions
A worker can finish right before its caller crashes. If the caller has not recorded the result, recovery may repeat that work.
Persist completed outputs and the state needed to continue at each delegation or handoff. A durable runtime can reuse recorded results and retry interrupted steps.
Make external operations idempotent so a retry does not repeat their effects. A payment may succeed even if its response is lost. Retrying it without a stable idempotency key can charge the customer twice.
Connect parent runs, worker calls, tool executions, and checkpoints with shared identifiers. Those identifiers let an investigator follow the work across agents after a failure.
Copy link to headingCheck authorization before tools execute
Delegation must preserve the permissions that apply to the task. A worker with access to payments or production changes needs the same authorization checks as an agent called directly.
Define which actions already have authorization, which require human approval, and which are prohibited. Apply that policy before execution.
AI SDK 7's toolApproval option lets ToolLoopAgent require approval through the 'user-approval' status. For longer waits, WorkflowAgent can suspend a durable run until a person responds, using its tool-level approval mechanism.
Copy link to headingImplement agent orchestration on Vercel
The pattern determines what the runtime needs to support. Parallel workers need concurrency controls. Runs that outlast a request need persisted progress. Workers that execute generated code need an isolated environment.
Choose a framework whose control flow your team can inspect, version, and test. Graphs and ordinary application code can both meet those requirements.
Copy link to headingDelegate through AI SDK tools
The AI SDK lets a parent invoke a subagent through a tool. The worker runs with its own context, and the tool determines which result returns to the parent.
This example gives a reviewer source notes to check against using ai@7 and zod, with AI Gateway.
import { ToolLoopAgent, tool, isStepCount } from 'ai';import { z } from 'zod';
const sourceNotes = `- ToolLoopAgent stops after 20 steps by default.- WorkflowAgent.stream() has no default step limit.- WorkflowAgent.generate() defaults to a maximum of 20 steps.- Both can use an explicit stop condition to bound model calls.`;
const reviewSubagent = new ToolLoopAgent({ model: 'anthropic/claude-sonnet-5.5', instructions: [ 'Review the draft against the supplied source notes.', 'Return factual inconsistencies and unsupported claims.', 'Do not treat model memory as evidence.', ].join(' '), stopWhen: isStepCount(5),});
const reviewTool = tool({ description: 'Check a draft against the supplied source notes.', inputSchema: z.object({ draft: z.string().describe('The draft to review'), }), execute: async ({ draft }, { abortSignal }) => { const result = await reviewSubagent.generate({ prompt: `Source notes:\n${sourceNotes}\n\nDraft:\n${draft}`, abortSignal, });
return result.text; },});
const orchestrator = new ToolLoopAgent({ model: 'anthropic/claude-sonnet-5.5', instructions: [ 'Write an answer using the supplied source notes.', 'Send the draft to the review tool, then revise it.', 'Avoid claims that the notes do not support.', ].join(' '), tools: { review: reviewTool }, stopWhen: isStepCount(20),});
const result = await orchestrator.generate({ prompt: [ 'Explain how ToolLoopAgent and WorkflowAgent limit execution.', `Source notes:\n${sourceNotes}`, ].join('\n\n'),});
console.log(result.text);The reviewer checks the supplied evidence. For broader factual reviews, provide authoritative documents or retrieval tools.
The instructions ask the parent to request a review. If review is mandatory, enforce the sequence in the application code rather than relying on that instruction.
A hierarchy repeats the delegation structure at another level. prepareStep can adjust models, tools, or messages between steps, while tool approval policies govern sensitive actions.
Copy link to headingPreserve progress with Vercel Workflows
An agent run may span several requests or wait hours for approval. Keeping its progress in process memory makes those interruptions difficult to recover from.
Vercel Workflows records progress for multistep applications. In TypeScript, the workflow and step directives separate orchestration from units of durable work. Completed steps have recorded results, interrupted steps can retry, and hooks let a run wait for external events.
Choose step boundaries around work whose results should survive an interruption. External actions still need protection against duplicate execution when a step retries.
Vercel's durable web research agent template records searches and extracted findings as workflow steps, preserving completed research across interruptions. FLORA uses durable orchestration for a different workload, coordinating more than 50 image models as its creative agent runs concurrent generation tasks.
Copy link to headingAccount for model wait time with Fluid compute
Parallel agent calls often spend much of their execution waiting for model responses. Check how a platform bills that time before estimating the cost of fan-out.
Fluid compute separates Active CPU usage from time spent waiting on input/output operations, including model calls. Concurrent requests can also share function instances. FLORA credits Fluid compute with keeping execution cost-efficient as its creative agent starts concurrent generation tasks.
Copy link to headingRoute models and control spending with AI Gateway
Triage and synthesis may need different models. Choose model routing strategies around the quality, latency, and cost requirements of each task.
Use AI Gateway to call models across providers through a single endpoint. Configure ordered model fallbacks to specify which alternatives it should try when a request fails or a model is unavailable.
Set AI Gateway budgets for teams, projects, API keys, or team members. The authentication method determines which budgets apply to a request.
These budgets are soft caps checked before requests. A request that crosses the limit can be completed, and budget changes can take time to propagate. Spending through bring your own key (BYOK) credentials does not count toward these limits.
Combine AI Gateway budgets with per-run usage accounting and execution limits when the application needs tighter control.
Copy link to headingIsolate code-running workers with Vercel Sandbox
Coding and data agents may execute generated code. Restrict what that code can access before running it.
Vercel Sandbox provides isolated Firecracker microVMs. Give workers separate sandboxes when they need separate VM boundaries. If workers share a sandbox, configure Linux users and file permissions to separate their files, and use groups for workspaces they need to share.
Use Sandbox.fork() to create a sandbox from the source's current snapshot. It does not copy unsnapshotted changes from a running session.
Each uninterrupted session supports up to 45 minutes on Hobby or 24 hours on Pro and Enterprise. Sandbox persistence carries saved state across sessions, so the session limit does not define the agent's total lifetime.
Configure outbound network access and credentials for each worker's task. The isolated environment does not replace authorization for the external systems it can reach.
You can start a Vercel project with one agent, or adapt an AI template, then add coordination after evaluation identifies a need.
Copy link to headingFrequently asked questions
Copy link to headingWhat is the difference between agent orchestration and agentic orchestration?
The terms often describe the same practice of coordinating AI agents. "Agentic orchestration" sometimes emphasizes model-driven planning and delegation. Specify whether code or a model controls routing, because the terminology alone does not establish that distinction.
Copy link to headingCan agent orchestration patterns be combined?
Yes. A system can use handoffs for initial triage, then give each specialist an orchestrator-worker setup for its subtasks. Define what state passes between layers and set limits both for individual agents and the complete run.
Copy link to headingHow does an orchestrator differ from a handoff?
An orchestrator retains control, invokes specialists, and combines their results. A handoff transfers responsibility to the receiving agent, which continues the task or conversation.
Use an orchestrator when one agent should own the final synthesis. Use a handoff when another specialist should take responsibility for continuing the work.
Copy link to headingWhen should you use group chat orchestration?
Use group chat when discussion or critique improves the result, such as a maker-checker review loop. Define acceptance criteria, cap the number of rounds, and decide what happens if the agents cannot produce an acceptable result.