Four Agent Orchestration Patterns and Who Decides What Happens Next

Imagine you have an AI support agent that works well. Then you add order lookups, address changes, and shipping reminders. Its toolkit grows to 30 tools, and the routing gets messy. An order lookup triggers a shipping reminder. A shipping request turns into an address change.

That could come from unclear tool descriptions, overlapping responsibilities, or the way requests reach the model. Splitting the work among specialist agents is one option when those boundaries help. It also introduces another question. Once a task has several parts, who decides what happens next, and who does it?

That is an orchestration question. Even a single agent needs rules for calling tools, continuing, and stopping. Here, we will focus on coordinating multiple agents.

Four useful agent orchestration patterns organize that control differently. They give us a way to compare designs, with room for other patterns and combinations.

Supervisor — The Manager Decides

A supervisor agent holds the coordinating role.

Think of ordering seafood pasta at a restaurant. The head chef assigns the shrimp to one station, the pasta to another, and the sauce to a third. Each station reports back. The chef decides whether something needs another pass or the dish is ready to serve.

In the agent version, specialists have focused instructions and tools. The supervisor uses the request and current state to choose a specialist, receive its result, and decide what to do next.

The advantage is flexibility. A different result can send the supervisor down a different route. That also gives you more paths to test. Debugging means following the routing decisions, tool results, and conditions for finishing.

Workflow — Your Code Defines the Routes

Picture an assembly line with specified operations and checkpoints. Different workers or machines can handle a station while the process still follows the routes you designed.

A model can write text or analyze an image inside a step. Code defines the sequence, branches, retries, and stopping rules. A model's output may select a predefined branch.

That makes the flow easier to predict and regression-test, though generated content can still vary. An unhandled case may require a new branch or a revised step. You have to maintain the process as the requirements change.

Handoff — The Current Agent Transfers Responsibility

In a handoff, the active agent transfers the conversation to another specialist. That specialist takes over the current interaction. A later transfer can return it to an earlier agent if the system allows it.

As a simplified analogy, imagine an emergency-department triage desk handing responsibility to a specialist team. The useful comparison is the transfer of responsibility between people handling the case.

An agent gets a configured set of available handoff destinations. When the request belongs elsewhere, it can select an appropriate destination from that set.

Handoffs can make a support conversation move naturally between areas of expertise. Longer chains take more work to trace. You need to know who took over, what context went with the conversation, and which tools became available.

Council — Parallel Reviews, Then a Chosen Aggregator

Here, several agents work independently in parallel. The application or operator decides when they start and how their results come together.

For a code-review example, imagine three agents assigned architecture-review roles. Each examines the same code and returns its findings. A person, an aggregation routine, or another agent then combines and assesses those findings.

Multiple reviews may expose different problems or assumptions. Reviewers can also share the same mistake, so the final assessment still needs evidence. Additional calls and context increase token use and coordination costs. The approach earns its place when evaluation shows that those extra perspectives improve the result enough to justify the expense.

How to Choose

For a task with clear routes, start with a code-defined workflow. For open-ended work with useful specialist roles, consider a supervisor. For conversations that need to move between domains, consider handoffs. For decisions that benefit from several independent views, consider a council with a budget and a clear aggregation rule.

Combining Patterns in One Project

Imagine a support service for VIP customers. An outer supervisor distinguishes an ordinary information request from a transaction problem. Transaction handling enters a workflow with defined permissions, checks, and any required confirmation. A risk-assessment step can ask several agents for parallel reviews, then assess their evidence. The workflow's authorization rules still govern any transaction.

That is hybrid orchestration. You can choose a pattern for each part of the task, combining them where the work calls for it.

Back to Who Decides

Some tasks fit comfortably inside one agent. When specialist roles help, decide where control belongs. A supervisor chooses assignments. Code defines workflow routes. The current agent selects a configured handoff. A council runs parallel reviews and brings them back through a chosen aggregation process.

Follow those decisions through your design, and you can see who owns the next step.