The Orchestrator Pattern

A customer asks to change the date of a booking. A researcher has found the terms, a developer has changed the code, a reviewer has approved the patch — but the price has changed and the charge has not yet been confirmed. Who decides what happens next, and what evidence will the system use to decide that the work is actually finished?

Learning outcome. After this unit you will be able to describe the boundaries between the roles of orchestrator, executor, reviewer and decision owner; define states and the criteria for moving between them; delegate work through a verifiable contract; resume safely after partial success; verify the integrated result; and recognise when a human decision is needed.

Prerequisites. You need a basic grasp of agents, context, decomposition and handing work over, as covered in How AI Coding Agents Work, Context as a Limited Resource, Handoffs Between Agents and Sessions and Codex Subagents and Orchestration. Only these general ideas are needed here; you do not need to know Codex's specific programming interfaces or its developer toolkit.

Orchestration is the management of work made up of several steps, executors or systems, so that together they produce a verified result. The orchestrator can be a program, a person, an artificial intelligence (AI) agent (a computer system that performs intellectual tasks), or some combination of these. A large language model (LLM), a model trained to understand and generate text, can analyse ambiguous material, but it is not needed at every step. The orchestrator's core job is to hold the goal and the state of the work, hand out bounded assignments, check evidence, reconcile results and decide what to do next.

Not every step needs a language model. Code is the better fit for predictable format checks, calculations, routing by a clear rule and repetitive operations. A person is needed where the decision belongs to an owner, carries legal or financial consequences, or depends on context the system does not have. A model is useful for ambiguous analysis, synthesising sources and generating options. A mature orchestrator picks the executor to suit the work rather than inserting an agent into every step.

This unit covers the general pattern and its limits. Delegating to Codex subagents is described in Codex Subagents and Orchestration; plugins and the Model Context Protocol (MCP), which standardises how models reach tools and data, in Plugins, MCP and Skills; and implementing an orchestration service in Building Your Own Orchestrator. Here we concentrate on state, contracts, verification, integration and the decision that the work is done.

Roles and responsibilities

The orchestrator holds the goal, assigns work, tracks dependencies and state, brings results together and decides the next step. It does not necessarily do any of the subject-matter work itself.

The executor is an agent, program, service or person entrusted with a particular result. The executor's contract bounds its goal, inputs, access rights, artefacts and stopping conditions. In a simple task one executor may play several roles, but the boundaries of responsibility still need to be clear.

The reviewer checks the result against defined criteria and evidence. It can be a person, a test, a separate agent, or several of these. A reviewer is not a magical source of truth: its verdict is one more artefact, which the orchestrator weighs for accuracy, coverage and independence.

The decision owner has the authority to make a decision the executor must not make on its own. This can be the user, an operator, the responsible team or a designated official. An owner's authority cannot be inferred merely from the fact that a model is able to propose an answer.

In a small scenario one person can be orchestrator, executor and decision owner all at once. In a larger process these functions are separated. What you separate is responsibility — not necessarily the number of agents. Decide who may change the shared contract, who accepts the integrated result and who authorises an external side effect.

The orchestration loop

A practical loop looks like this:

goal and starting state → plan with explicit dependencies → bounded assignments → execution → verification → integration → decision: continue, stop or finish.

Each arrow stands for handing over a concrete artefact or state, not just a "done" message. First the orchestrator clarifies the goal and checks that the sources it needs are authoritative. The plan is a working hypothesis about the order of work. When new evidence arrives, the orchestrator may revise it, keeping the reason for the change and the results already verified. In OpenAI's documentation a manager can call a narrow specialist as a tool and remain responsible for the final answer, or hand control over to it through a handoff; these are two different patterns in an application programming interface (API), an agreed way for programs to exchange requests and responses, rather than universal roles for every system (OpenAI Agents orchestration). Anthropic additionally distinguishes workflows (predefined sequences of work) from agentic systems, in which the model dynamically chooses its next actions (Building effective agents); these are terms from their architectural guidance, not a boundary dividing every possible system.

Before delegating, the orchestrator states the goal and establishes the starting state: what is already known, which changes have already been made, which permissions exist and which conditions must not be violated. It then breaks the goal into results with verifiable criteria. It parallelises only those parts that have explicit boundaries and do not depend on each other while running. After execution it checks not only each result on its own but also the coherence of the whole.

A model that chooses its own next step does not remove the need for a boundary on the loop. Set a budget for calls, time, cost or attempts, and a stopping condition. If there is no new evidence, regenerating the plan is not progress.

The assignment contract and acceptance criteria

A good assignment lets the executor act independently within limits and lets the orchestrator accept or reject the result independently. A minimal contract includes:

Field	What to record
Goal	What result is needed, and for whom?
Scope	Which parts are included and which are excluded?
Input and revision	Which sources, files, data or versions are authoritative?
Executor and permissions	Who does the work, what may they read or change, which actions are forbidden?
Artefact	What exactly must come back: an analysis, a file, a patch, a request or a decision?
Acceptance criteria	Which observable conditions will show that the result meets the goal?
Evidence	Which sources, checks, logs or results must be provided?
Dependencies	What must be ready first, and which other work does this result block?
Budget and time	What are the limits on cost, duration or number of attempts?
Stop condition	When should the executor stop and escalate instead of guessing or changing the scope?

Criteria should describe properties of the result, not the number of messages or the mere fact that the executor finished. "Return three sources with dates and quotations" can be checked. "Research it well" cannot. If a criterion is subjective, break it down into observable features and leave room for the owner who makes the value judgement.

The contract should carry the context that is needed, not the whole history of the work. Pass on the starting revision, decisions, assumptions, required links and the changes since the last review. Require the executor to name unknown facts, assumptions and incomplete parts separately. This helps avoid mistaking a conclusion for a fact.

State is something you manage

The current state must be explicit and recoverable. Example state names: planned, ready (ready to start), running, blocked, needs_review, accepted, failed, cancelled. This is a convenient vocabulary, not a mandatory schema. A project should choose its own states and define what they mean.

Transition	Required condition or evidence
planned → ready	Scope, dependencies, executor, access and criteria are sufficiently defined.
ready → running	The launch is recorded with an identifier, a revision and a budget.
running → needs_review	The executor has returned an artefact and a report; this is not yet acceptance.
running → blocked	There is a specific external blocker or a missing permission; the owner of the next action is named.
needs_review → accepted	The required criteria have been checked against a specific artefact or revision.
needs_review → running	The rejection, its criterion and a bounded fix are recorded.
running → failed/cancelled	The reason, the partial state and any possible external consequences are recorded.

A terminal state does not mean that every part succeeded. A cancelled task, for example, may already have created an external resource. Keep the executor's status, the artefact's status and the status of the external operation separately whenever their life cycles differ.

Every state change has an author, a time, a previous value, a new value and a justification. For an important transition, store a link to the evidence: a diff (a comparison of versions), a check run, an API response, the owner's approval or the observed state of the system. After recovery, do not trust a stale local "done" message — check the current external system.

Decomposition, dependencies and parallelism

Decomposition is useful when the result of a subtask can be verified independently and passed on through a clear interface. Two tasks can run in parallel if their data, permissions and results do not create mutual writes without coordination. If two executors need to change the same file, a shared schema or a single decision, appoint an integration owner or split the interface before running them in parallel.

A dependency graph answers three questions: what must be ready first; what can be done at the same time; and which contract connects the parts. Do not start a subtask if its input is still changing without a revision, or if its acceptance criteria depend on a decision that has not been made. Stop or replan the work when its preconditions are no longer valid.

Coordination itself has a cost. In The Mythical Man-Month, Frederick Brooks describes the communication overhead for people working on tasks that require mutual coordination, and defends conceptual integrity as a principle of architecture (bibliographic record; text of the book). His stylised model of pairwise links is not a forecast of team productivity, nor proof of any law for AI agents. The practical conclusion for an orchestrator is to fix the shared interfaces, limit the number of dependencies and keep an owner for system-level decisions. Carrying this idea over to agents is our own engineering interpretation, not Brooks's claim.

In Team Topologies, Matthew Skelton and Manuel Pais describe different interaction modes between human teams: time-boxed collaboration, a service with a clear owner, and temporary facilitation (the book; interaction modes). These modes can suggest how to describe the boundaries between agent roles, but the book does not prove that such a structure will improve an agentic process. Choose the smallest interaction that delivers the knowledge or service you need, and decide when it ends.

Verification and integration

A single subtask can pass its own checks and still break the overall result. The orchestrator checks two things: the local correctness of each artefact and the system compatibility after everything is combined. For each sub-result, record the revision of its inputs, the version of the criteria and the exact result of the check. If the input changed between verification and integration, rerun the checks that depend on it.

The evidence must match the claim. A link to a test run does not prove that the test covered the particular defect, and a finished continuous integration (CI) run does not prove that the latest artefact was checked if the revision does not match. A reviewer's response is evidence only about what the reviewer actually read and checked. Record both positive results and gaps.

Before accepting a result, combine the separate versions, apply the changes, resolve conflicts and re-verify the integrated system. A shared list of "done" tasks does not guarantee that their artefacts are compatible. Check the order of migrations, the exchange format, shared conventions and the user-facing result that emerges once the parts are assembled.

A real example from a Kubernetes controller shows why a partial state must stay consistent. Bug report #139428 describes a path in which a Job — the Kubernetes resource that launches and tracks a finite task — was repeatedly deferred: its active value became zero while ready still reflected active Pod objects (a Pod is one or more containers sharing an environment). The Kubernetes API rejected the inconsistent update with error code 422, which delayed saving the status and removing the tracking finalizers. The related pull request (PR) #139457 restores a consistent count of active tasks in two deferred-creation paths and adds regression cases for both the ordinary and the indexed path. It was merged on 11 June 2026. This is not an example of an AI agent and not a productivity measurement: it illustrates how partial state, an API rejection, recovery and test integration are connected within one controller. The PR page does not confirm green continuous integration (CI) checks, so no such conclusion is drawn here.

Retries, partial success and recovery

A retry without a check can double an external effect. An executor might have created a booking, sent a message or written a change, and then been cut off before returning confirmation. A timeout status tells you that the orchestrator did not get a response in time; it does not tell you whether the operation happened.

Before retrying, read the actual state of the external system by operation key, identifier, natural key or some other reliable means. If the system supports an idempotency key (a repeated request with the same key creates no new effect), reuse it within the same logical operation. If it does not, first establish whether the earlier action took place; when that is impossible, stop and pass the uncertainty to the owner. The LangGraph documentation describes a related boundary in its own implementation: after an interrupt, a node may start again from the beginning, so code placed before the interrupt point has to tolerate being re-executed (Interrupts).

Recovery needs a durable record: the goal, the plan version, the state of each step, input revisions, artefacts, the last successful check, unresolved assumptions, external actions already performed, and the next safe step. Reopen the sources of truth after a break. Resume only the missing part, and only if its preconditions still hold; a stale plan must be recalculated.

Retry only steps that have an attempt limit, a time budget and an explanation of how exactly the new attempt will reduce uncertainty. Exhausting the limit moves the task to blocked or failed with a short report — not into endless generation of the next plan.

Human decisions and reviewer disagreement

Human control is needed where authority, consequences or unresolved values demand it. That could be confirming a charge, sending an external message, publishing, deleting, choosing a policy or resolving a conflict between different interests. An agent may prepare options and evidence, but it must not take the owner's authority for itself.

Give the owner a concise decision: the question, the options, the consequences, the sources, the level of uncertainty, and a recommended option with its grounds. Store the answer and its limits in the state log. If the price, recipient, scope or risk changed after approval, the earlier approval may no longer match the facts — check its conditions before acting.

When reviewers disagree, compare their claims first, not their overall verdicts. One may dispute a source, another the interpretation, a third the criterion or the limit of authority. State the specific dispute, gather the minimum decisive evidence and ask for an independent check of exactly that question. If the disagreement is about a fact, you can look for better data; if it is about a criterion, let the owner clarify the criterion; if it is about policy or values, put the decision to a person. Do not average incompatible conclusions, and do not treat a vote count as proof of correctness.

Cost, limits and a legible result

The full cost of orchestration includes model and tool calls, waiting, transferring context, CI, review, integration, fixes and human attention. Parallelism shortens calendar time only when the work is independent; it does not guarantee lower total cost. Add an executor if it produces an independently acceptable result and the value exceeds the cost of setting the work up and integrating it.

Measure completed, accepted results, the time to reach them, the number of rework cycles, duplicated external effects and human escalations. The number of agents launched or messages produced is not a success metric. Start with a single executor; split the work when the contract, the load or the required expertise genuinely differ. Premature splitting creates more hand-off points, more sources of state and more places where responsibility gets lost. Anthropic's own report on its research system also describes duplicated subtasks and spawning too many agents as problems they observed — not as a measure of universal productivity (report).

In The E-Myth Revisited, Michael Gerber distinguishes working in the business from working on the system that gives the team a repeatable foundation (book page; EMyth explanation). Here we carry that management metaphor over to orchestration: automate the routine loop so it can be observed and repeated without relying on the dispatcher's hidden memory. Gerber wrote about small businesses, not about AI or software agents; the transfer is an analogy. A formalised process must stay open to change: record the rules, revise them in the light of evidence, and do not turn untested assumptions into automatic policy.

Three worked examples

These are fictional teaching scenarios. The artefacts and results described below show the conditions under which each scenario could be accepted; no external operations or checks were actually run for this unit.

Changing a booking: research, implementation, review

Goal. Add the ability to change a booking's date without losing its history and without allowing a double charge. The starting state contains booking B-381, the current price and the identifier of the last transaction. Rule: a date change may change the price; the customer confirms the final price.

The orchestrator creates three dependent assignments. The researcher reads the requirements and the payment provider's API and returns sources, constraints and uncertainty; it may not change any data. The implementer receives the approved API contract and a code revision, and adds a change operation with an idempotency key and an audit log; it may not make a real charge. The reviewer checks edge cases, history and retry conditions against a specific recorded version of the changes (a commit). Implementation starts after the API contract is accepted, and integration testing starts after both artefacts exist.

Before anything runs, the evidence for each subtask's transitions is defined separately. A returned research note with primary sources moves the research from running to needs_review; checking the sources against the acceptance criteria moves it from needs_review to accepted. The approved contract, its error conditions and the idempotency key become the input to implementation and justify ready → running; the code changes and targeted checks justify running → needs_review; the reviewer's verdict and integrated checks on the same commit justify needs_review → accepted.

In the test environment the customer picks a new date. The system reads the current price, builds the request and stores it as a pending change. If the amount has changed, the customer's external confirmation is a separate human step; once the date or the price changes, the approval no longer holds. Only then is the charge or refund carried out. Suppose integration testing returned a booking history with a single operation identifier, the payment provider and the local record showed the same amount, and repeating the request with the same key did not create a second charge. This set of observations is the basis for accepting this particular revision of the changes. If the provider's API is unavailable, the task moves to blocked rather than trying to guess the outcome of the payment. Such a split would be excessive for a purely internal date change with no price change and no external operation: there, one executor and a local check are enough.

An executor stopped halfway through

Goal. Update 40 customer signatures. After the 20th, the executor lost its connection. There is no report. The orchestrator assumes neither complete success nor zero progress.

First it reads the remote list and the log, checks the records one stable identifier at a time and compares them with the initial snapshot. It finds 18 updated, two tasks in an uncertain state and 20 unchanged. The orchestrator saves this inventory, the action identifiers, the source values and the revision. For the two uncertain cases it checks the actual state individually rather than sending a new invitation. The log check shows that the first signing has already succeeded, while no invitation was ever sent for the second. So the state becomes 19 completed and 21 unchanged records; only those 21 are resumed.

If the external system has an idempotency key, a retry of the uncertain operation reuses the same key. Otherwise, a check or a human decision is required. The finished result is not "the second agent replied" but all 40 desired states being in place, one record per required change, and the uncertainty resolved. State and acceptance evidence are kept separately for each part. This process is needed when actions may already have had external consequences; for reading documents or another operation without side effects, a safe retry can be simpler than a full log reconciliation.

Two reviewers disagree

Goal. Approve an update to the refund rule. Reviewer A says the calculation does not account for partial refunds; reviewer B says the example in the test is out of date. They do not vote on an overall "good/bad" verdict.

The orchestrator splits the dispute into two claims: does the payment contract support partial refunds, and does the test check current behaviour? In this fictional scenario the provider's current specification confirms partial refunds, and the existing test checked only full ones; a targeted check reproduces the gap. That resolves the factual dispute but leaves a decision for the owner: is a partial refund a mandatory product criterion? The owner says "yes", so the criterion is added to the contract, the implementer updates the handling of partial refunds, and the reviewers check the same new code revision and the result of the targeted test. This chain of evidence, not a vote, is the basis for acceptance.

The result is not accepted just because a third opinion has been added. Acceptance follows the recorded owner's decision, the implementation's compliance with the clarified criterion, and an integrated check of the revision under consideration. If the dispute concerns only a verifiable fact, and the current criterion and the authoritative source are unambiguous, no separate policy escalation is needed; if the owner is unavailable, the work stays blocked, and the agent does not choose the product trade-off by itself.

Summary

An orchestrator finishes a task when its integrated result meets the criteria on a specific revision, the required evidence is stored, uncertain side effects have been resolved, and the owner's decisions have been obtained wherever they are needed. Until then, an assignment may be complete while the goal is not yet accepted. When the work cannot safely be retried or finished without a missing decision, the orchestrator explicitly records the blocker and the next responsible step.

Sources and further reading

Dynamic content was checked on 26 September 2026.

1. OpenAI, Agents orchestration, official description of the manager, agents as tools, and handoffs; accessed 2026-09-26.
2. Anthropic, Building effective agents, 19 December 2024. Workflows, routing, parallelization, orchestrator-workers, evaluation and human checkpoints; accessed 2026-09-26.
3. Anthropic, How we built our multi-agent research system, 13 June 2025. Anthropic's architecture and observations about its own research system; the experience is not generalised to all projects; accessed 2026-09-26.
4. LangChain, Interrupts, official LangGraph documentation on pausing, resuming and idempotent side effects; accessed 2026-09-26.
5. Kubernetes, Issue #139428, bug report on Job status, 2 June 2026; and PR #139457, the fix and regression checks, merged 11 June 2026; accessed 2026-09-26.
6. Michael E. Gerber, The E-Myth Revisited, book description on the author's site. Its use in this unit is an analogy drawn from business operating systems; page checked 2026-09-26.
7. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley, 1995, chapters "The Mythical Man-Month" and "Aristocracy, Democracy, and System Design"; Google Books bibliographic record and text of the book at Carnegie Mellon. The coordination model is not a universal forecast for agents; source checked 2026-09-26.
8. OpenAI Agents SDK, Multi-agent, Handoffs and Human in the loop: documentation of specific orchestration interfaces; accessed 2026-09-26.
9. Matthew Skelton and Manuel Pais, Team Topologies and team interaction modelling: human team models, not evidence of an effect on AI agents; pages checked 2026-09-26.
10. EMyth, Work ON it, not just IN it: source of the management analogy, not research on orchestration; checked 2026-09-26.