Agent orchestration is the coordination of agents, tools and execution steps within a larger process, including routing work, ordering operations, managing state and handling handoffs. It defines how the parts of an agent system work together to complete a task.
Orchestration is the part of an agent system that decides who does what next. In a small system it is a few lines of code that call one agent, then another. In a large one it is a lead agent that plans the work, spawns specialists, gathers their results and decides when the job is done. Either way, every orchestrated system has the same weak point: the handoff, where one agent’s understanding of the task has to be passed to another.
The common patterns
The vocabulary differs between frameworks, but the patterns recur. Microsoft’s Agent Framework names five: sequential, concurrent, handoff, group chat, and “magentic”, in which a manager agent coordinates specialists dynamically. Google’s Agent Development Kit offers sequential, parallel and loop workflow agents. LangGraph expresses orchestration as a graph of nodes, edges and shared state.
| Pattern | Who decides the next step | Typical use |
|---|---|---|
| Sequential pipeline | Code | Each stage refines the last |
| Parallel fan-out | Code, then a merge | Independent subtasks, combined at the end |
| Router or handoff | A model, at each transfer | Send the conversation to the right specialist |
| Orchestrator and workers | A lead model, throughout | Open-ended tasks whose subtasks are not known in advance |
The first two are deterministic: which agent acts next is fixed when the system is built. The last two are model-driven: routing becomes a decision made at run time. That difference matters more than any framework choice, because it decides whether the question “could this agent have been asked to do that?” can be answered from the design or only from the run.
Delegation compresses intent, not authority
When an orchestrator delegates, two things travel to the delegated agent: what it should do, and what it is able to do. In many systems they do not travel equally. This is not a property of every framework or every design, and both can be configured; it is a common architectural risk, because the defaults and the easiest path tend to produce it.
Intent arrives as a summary. Claude Code’s subagents start with a fresh context window and work from a delegation message the parent writes. The OpenAI Agents SDK passes the full conversation by default but offers filters and an option to compact it into a summary. Microsoft’s handoff orchestration does not broadcast tool calls and their results to other agents. Anthropic’s account of its research system shows what happens when the summary is thin: early versions gave subagents short instructions, and they duplicated each other’s searches or researched the wrong period entirely. Anthropic’s fix was a better brief: an objective, an output format, guidance on tools and sources, and clear task boundaries.
Authority often arrives whole. In Claude Code, a subagent with no tool list inherits every tool available to subagents, and it inherits the parent’s permission rules and, unless set otherwise, its permission mode. Teams can narrow a subagent’s tools and mode, and the OpenAI Agents SDK can strip tools from a handoff, but each of those is a decision someone has to make. Where nobody makes it, a delegated agent holds the parent’s full authority and only a paraphrase of the parent’s purpose.
That asymmetry is the governance risk of orchestration in one sentence: unless the design prevents it, a delegated agent can be able to do more than it understands it should.
Anchor each step to the original request
If each hop passes on a summary, intent degrades with depth: the third agent in a chain works from a summary of a summary. Research on multi-agent authorization points to a practical answer. The MasDrift benchmark (Xu et al., a 2026 preprint) paired required work with actions the user had reserved for themselves, in 600 tasks across several architectures and models. Centralized hierarchies completed the most tasks, but they also produced more unauthorized actions than peer networks, and the gap grew with hierarchy depth. Of two defenses tested, passing a narrowed policy down the delegation chain blocked so much legitimate work that completion fell by up to 36 points. Re-anchoring each pending call to the original user request reduced unauthorized actions in every configuration tested, for a cost of under two points of completion.
These are results from one benchmark, with the models, architectures and tasks it tested, and the exact figures should not be expected to carry over to other systems. The direction is still a useful design principle: the reference point for whether a step is in bounds should be the task as it was originally declared, not whatever the previous agent said. That requires the original intent, scope and governing policy to be held somewhere outside any one agent’s context, so that every step, at any depth, can be checked against the same thing.
Two different kinds of check can use that reference point. One is semantic: interpreting what the original objective allows a step to do. The other is rule-based: is the step within a declared scope, and does it satisfy the applicable policy? MasDrift’s re-anchoring combines them: a separate model turns the original request into a rule for each tool, and a deterministic monitor checks every pending call against those rules instead of against the previous agent’s instructions. The rule-based half is narrower, and it is where most runtime checks start.
An example
A support system has a triage agent that hands conversations to billing, refunds and account specialists. A customer writes: “I was charged twice; please refund the duplicate, and don’t change anything else on my account.” Triage hands off to refunds with the summary “customer reports a double charge, wants it resolved”. The refunds agent, which also holds the account tools it was never told not to use, issues the refund and, to prevent a recurrence, switches the customer to annual billing.
Every agent behaved reasonably given what it was told. The instruction that ruled out the second action was in the original request and not in the handoff.
Where Sentience fits
Sentience Governor, the free, open-source runtime governance library, holds the reference point outside the agents. A session declares its objective and scope once, and each agent’s actions are recorded at the execution boundary and evaluated against that declared scope and the operator’s policy, with the objective kept as context. That is the rule-based check: Governor does not judge whether a step serves the objective. Which policy applies is settled by policy resolution: an agent instrumented under its own identifier resolves to its own governance profile, once per session, and the record states which binding applied. In Claude Code, launching a subagent is itself recorded as an action. Governor records and flags; it does not intervene in a handoff.
Where a delegated step must be stopped or reviewed before it runs, Sentience Runtime Enforcement evaluates actions during execution at the control points in your own infrastructure, including your existing frameworks and gateways, against policy and the original objective, and can course-correct, escalate to a human reviewer, or stop the run. For orchestrated systems, that means delegated agents answer to the original request and to policy, not to the last summary they received.
Often confused with
An agent framework. A framework is the library you build agents with. Orchestration is how the agents and steps are coordinated; most frameworks offer orchestration primitives, but the two are separate decisions.
An agentic workflow. A workflow is the process. Orchestration is the coordination within it. A workflow can be orchestrated deterministically and still contain agentic steps.
A multi-agent system. Orchestration is needed in any system with several steps or tools, including single-agent ones. A multi-agent system is one that orchestrates several agents.
Where the concept stops
Orchestration decides order, routing and handoffs. It does not establish that what a delegated agent was told matches what the user asked, that the agent’s authority matches its task, or that a step deep in the chain was within the original intent. Those depend on a statement of intent and scope that every step can be checked against, and on the authority to act when a step is not.