An orchestrator agent is an AI agent whose job is to coordinate other agents: it reads a piece of work, breaks it into tasks, assigns each task to the agent suited to it, checks results and decides what happens next. It manages rather than does. Because its decisions shape what every other agent does, it needs the highest bar of proof in the system.
What does an orchestrator agent do?
It plans and delegates. Given "onboard this business customer", it might decide the steps are: collect documents, verify the company, screen the directors, prepare the account file. It assigns each step to a specialist agent, passes along the facts each one needs, watches for failures, and re-plans when something unexpected comes back, such as a director appearing on a screening list.
What it should not do is the specialist work itself. An orchestrator that also screens, verifies and drafts becomes a single large agent with a misleading name.
Why does an orchestrator need special treatment?
Because coordination is a capability with reach. An orchestrator that mis-plans can send work to the wrong agent, skip a required step, or combine results in a way no single agent would. And because it talks to every other agent, it is the natural route for authority to leak: an orchestrator cleared for one thing asks a sub-agent to do something the orchestrator itself could never do.
That is why, in our depth scale, coordinating other agents is depth 5, open only to orchestrators and earned like any other depth.
How does an orchestrator agent work in practice?
It receives a task with its facts and their provenance. It produces a plan. For each step it sends a task to a sub-agent, through the same control layer every other action goes through. The sub-agent acts under its own bounds. The orchestrator collects the results, checks them against what the step was meant to produce, and moves on or escalates.
The delegation rules are covered in how an orchestrator agent should delegate work, and the setup across several agents in how to run several AI agents under one orchestrator.
What does that look like in an example?
A corporate card provider's dispute process has an orchestrator and three sub-agents: one gathers transaction details, one collects the cardholder's evidence, one drafts the chargeback submission. The orchestrator notices the cardholder's evidence includes a merchant email promising a refund. It does not tell the drafting agent to cancel the dispute. It records the email as external, asks the evidence agent to confirm the refund in the signed transaction record, and holds the case until it either appears or a person decides.
How is an orchestrator agent different from an orchestration layer?
An orchestration layer is usually fixed logic: a workflow engine that runs steps in a set order. An orchestrator agent decides the steps as it goes, using a model. The layer is predictable and rigid; the agent is flexible and needs to be bounded and certified. Many systems combine them: fixed steps for the parts that must always happen, an orchestrator agent for the parts that vary.
Can an orchestrator give a sub-agent more authority than it has?
It should not be able to. Delegating a task is not delegating authority. Each sub-agent acts under its own certificate and bounds, and the orchestrator's request is one input to that check, not a permission. The full argument is in can an orchestrator agent give a sub-agent more authority than it has? The wider architecture is in the governed agentic operating system, explained.
Questions people ask
Does every multi-agent system need an orchestrator agent?
No. Many work well with fixed workflow logic deciding which agent runs next. Use an orchestrator agent where the steps vary enough that fixed logic becomes unmanageable.
Who is accountable for an orchestrator's decisions?
The business owner of the process it runs. An orchestrator can plan, but a named person answers for the outcome and for any action it holds for review.