Orchestration

AI orchestration coordinates every part of one AI-supported job. It tells models, agents, tools, people, and fixed workflow steps what runs next, what information moves between them, when a failed step retries, and when the run stops. OpenAI describes single-agent and multi-agent designs and recommends adding complexity slowly. A single agent with four tools can still need orchestration when the job can branch, stop, or touch client systems. The useful test comes when the happy path breaks. A working system shows the failed step, preserves completed work, stops before a risky action, and gives a named person enough context to recover it. Orchestration is the layer around the work. It turns connected tasks into one run that someone owns.

What does orchestration control?

Orchestration controls what happens around the AI during the whole run. A model may draft a proposal. The orchestrator decides which transcript to fetch, which pricing rule to apply, where the draft goes next, and what counts as finished.

The operating decisions are simple to name:

• the order and timing of steps;
• the information passed between steps;
• the tool or person used for each step;
• when to retry, stop, or ask for help;
• the record kept when the run ends.

OpenAI’s guide to building agents says every agent run needs an exit condition. It may end with a defined output, a final tool call, an error, or the allowed number of turns. Without a limit, an agent can keep searching, revising, or handing work away after the useful part is over.

An orchestrator also keeps state. It knows which steps finished, which information they produced, and what can safely run again. That history matters after a timeout or an approval pause. The next person should resume the run instead of starting from the beginning.

What does orchestration look like in a service firm?

Take a proposal after a discovery call. The system collects the approved transcript, matches the prospect to the correct CRM record, applies the current pricing rule, drafts the document, sends scope and price for review, and files the approved version.

If the CRM contains two companies with similar names, the run should stop before it joins the wrong history to the proposal. If the pricing rule is missing, drafting a polished document is wasted work. If the reviewer changes the scope, the final version must carry that change into the document and the CRM.

A green check beside the drafting step proves little when the filed record and the sent proposal disagree. The system needs a final record that a person can inspect. A person running a demo may notice a missing price and paste it in. A production run at 2 a.m. needs a written rule for the same event.

This is one edge of the Production Gap. The model may work while the system around it fails. Orchestration closes part of that gap by making handoffs, state, and recovery explicit.

How is orchestration different from a workflow?

An AI workflow defines the path work should take. Orchestration runs the steps and coordinates what happens inside and between them.

A workflow says: take a transcript, extract requirements, draft the proposal, review the price, then file the approved version. The orchestration decides whether extraction and CRM lookup run together, which agent drafts, what the reviewer sees, and how the run resumes after a correction.

Ordinary automation follows rules written in advance, such as copying an approved PDF into a client folder. An agent can make one limited decision inside the flow, such as deciding whether the transcript contains enough detail to draft. Orchestration coordinates both without turning every step into an agent.

Anthropic’s guidance makes a similar split. Workflows follow paths defined in code. Agents direct more of their own process and tool use. Both still need a surrounding system that knows the job’s state.

Term	What it controls	Proposal example
Automation	One rule-based action	Copy the approved PDF into the client folder
Workflow	The fixed order of steps	Extract, draft, review, then file
Agent	A bounded decision inside the work	Decide whether the transcript has enough detail to draft
Orchestration	The run across every step and handoff	Match the CRM record, apply pricing, route review, and save the result

The workflow is the planned path. Orchestration is the operating system for a run on that path. It can coordinate a workflow with no agents, one agent, or several agents.

Do you need several agents?

Most firms should start with one. More agents add handoffs, more context to manage, and more places for responsibility to become unclear.

One agent with clear instructions and a small tool set can run a substantial job. OpenAI recommends expanding one agent’s tools before splitting the work across several. One run is easier to trace, test, and change than a conversation among specialists.

Add another agent when the boundary is real. A proposal writer and checker may need different instructions and access. Research may run beside a CRM lookup because neither depends on the other. A handoff helps when the right specialist becomes clear only after the system reads the request.

Use a fixed sequence when the order is known. Run independent steps together when that is safe. Keep one model when it can complete the job and pass the tests. The point of orchestration is to make responsibility clearer, not to fill a diagram with agents.

What breaks in bad orchestration?

Bad orchestration hides partial failure. Five steps run, four succeed, and the final screen says only that the job failed. Someone starts it again. The CRM gets two activities, the file store gets two drafts, and the reviewer receives the same request twice.

A safe retry needs to know whether a step already wrote something. A read can often run again. Sending an email or changing a client record may not be safe to repeat after a timeout. The system needs a record of the last successful step and the state of each write.

Context also gets lost between agents. The first agent finds that the client rejected a certain scope last quarter. The second receives the transcript but not that decision. Each component performs its assigned task, and the system produces the wrong proposal.

A writer and checker can loop forever. The writer revises, the checker rejects, and the cycle repeats. Microsoft’s agent design guidance says these loops need clear pass criteria, a maximum number of rounds, and a fallback.

Human approval can fail in the same way. The system pauses without saving state, so a price approval the next morning restarts the whole run. Microsoft recommends saving state at mandatory approval points so completed work does not replay.

How should you design the first orchestration?

Draw the work first. Map one run from the event that starts it to the record that proves it finished.

For each step, write its input, output, owner, stop condition, and whether repeating it is safe. A step that sends an email or changes a client record should not repeat because a later step timed out.

Then place the human decisions. OpenAI recommends intervention when a run exceeds its failure threshold or reaches a high-risk action. In a service firm, that often means price, scope, a promise to a client, a payment, or a change that is hard to undo. The person should receive the decision that needs judgment and the evidence behind it, not a blank approval button.

Make failure visible where the work is managed. A failed proposal run should appear on the delivery board with the prospect, failed step, last successful step, and named owner. An error stored only in the AI tool belongs to nobody.

Test the unhappy path. Try a missing price, two matching client records, a rejected draft, and a tool that times out after writing. The system should stop in a known state each time. A successful run proves that the parts connect. Recovery proves that the orchestration can carry client work.

Where does orchestration sit on the Delivery Model Ladder?

Orchestration becomes structural at Stage 2, Augmented, on the Delivery Model Ladder. This is the point where the firm rebuilds a workflow around AI. The system, rather than one employee with a chatbot, starts coordinating work across tools and review steps.

Stage 3, AI-native, can use more dynamic orchestration. Agents may route work, choose tools, and own defined slices of delivery. The architecture alone does not earn the rung. Stage 3 shows up when delivery results stop tracking headcount and the firm can verify what agents produce.

A complicated multi-agent system can sit at Stage 1 if people work around it and delivery stays unchanged. A plain sequence with one model, one approval, and reliable recovery can be a solid Stage 2 system.

Quick answers

Is orchestration the same as automation? No. Automation performs predefined actions. Orchestration coordinates those actions with model decisions, agents, tools, and people across the whole run.

Does orchestration require multiple agents? No. One agent using several tools needs orchestration when the run has branches, exit conditions, retries, or approval points.

Who owns orchestration after launch? One named person should own the workflow end to end. Tool owners can maintain individual steps, but one person remains accountable for the final client outcome and the recovery path.

Where should a human enter the run? At decisions that need judgment or create a hard-to-reverse consequence. Put the gate before the action and give the reviewer the context needed to decide.

What should you monitor? Completion, time per step, retries, failed handoffs, human escalations, and duplicate or conflicting writes. Monitor the final record too. A run that says complete while the CRM is wrong did not complete.