The Ward Coordinator Is Not the Attending Physician
A hospital ward runs on coordination. A patient is admitted, and the ward coordinator books the consults — cardiology in the morning, nephrology after lunch, a pharmacist review before evening rounds. Each specialist examines the patient through their own lens, writes their notes, and leaves. The coordinator collects everything and assembles the chart.
Then cardiology recommends a medication that nephrology says the patient's kidneys cannot tolerate.
The coordinator does not decide which specialist is right. Not because the coordinator is unqualified to have an opinion — but because the coordinator's job was never to decide. That authority belongs to the attending physician of record. And critically, the attending was named on admission. Nobody goes looking for one at the moment the two notes contradict each other.
Most multi-agent AI systems have built an excellent ward coordinator. Very few have named the attending.
The Wrong Diagnosis
When a multi-agent system misbehaves, the post-mortem usually lands on a coordination problem. The context window was too small. The handoff between agents dropped information. The routing logic sent the task to the wrong specialist. The fix is a better prompt, a bigger context, a smarter router.
Sometimes that is the right diagnosis. Often it is not.
Look closely at the failures that are hardest to explain afterwards, and a different pattern shows up. Every agent did its job. Each produced a reasonable output within its own lens. The security agent flagged a risk. The code-generation agent produced a working change. The cost agent recommended a cheaper configuration; the reliability agent recommended a more resilient one. The coordination worked perfectly.
What failed was that two correct-in-isolation outputs disagreed, and the system had no answer for whose output should win. So the orchestrator — the one component that sees both — answered the question itself. Nobody noticed, because from the outside it looked like coordination.
That is not a coordination problem. It is an authority problem wearing coordination's clothes.
Synthesis Is a Decision
The orchestrator pattern is now the default way to build systems that do more than one agent can handle alone. Anthropic's own description of it is precise: multi-agent architectures "use an orchestrator to coordinate specialized agents working in parallel—each with dedicated context—then synthesize results into integrated output."
Read the last clause again. Synthesize results into integrated output.
When the results agree, synthesis is assembly. When they disagree, synthesis is a decision. There are only three things an orchestrator can do with two conflicting outputs, and every one of them decides something:
It picks one. The orchestrator — or the model behind it — weighs the two outputs and selects the more plausible. That is adjudication. The orchestrator has just exercised authority over two agents that were each, in their own scope, entitled to decide.
It blends them. The orchestrator produces a compromise neither agent proposed. That is a third decision, made by a component that was never given decision rights over either domain.
It passes both up. The orchestrator surfaces the conflict to a human. That looks like the safe option — until it happens for every conflict, at which point the human becomes the system's only real arbiter, by exhaustion rather than by design.
None of these is wrong in every case. What is wrong is that in most systems, which of the three happens is not written down anywhere. It is an emergent property of a prompt.
Applying AIDRA to the Orchestrator
This is not a case for a new framework. AI Decision Rights Architecture (AIDRA) already names the three dimensions that govern an agent's authority: Delegation Scope, Autonomy Class, and Escalation Protocol. Applying AIDRA to team design asked who on the team owns each boundary. This piece asks a narrower, architectural question: where in an orchestrated system does each boundary get enforced?
The answer is the orchestrator — not as the arbiter, but as the enforcement point. The orchestrator is the only component that sees every agent's scope, every agent's output, and every conflict between them. That makes it the right place to apply decision rights, and the worst place to invent them.
This also builds on established work rather than replacing it. The orchestrator-worker pattern is well documented and works. AIDRA does not change how the orchestrator routes or how agents execute. It adds the one thing the pattern was never designed to carry: a rule for who wins.
Dimension 1: Delegation Scope, Checked at Routing
Overlapping scope is the root cause of most merge-point conflicts. Two agents are both entitled to decide the same question, so both do. The cheapest place to catch that is before either one runs.
| Routing Situation | What It Means | What the Orchestrator Should Do |
|---|---|---|
| One agent in scope | Exactly one agent holds delegation for this decision | Route normally |
| Several agents, non-overlapping | Each agent decides a different part of the task | Route in parallel; synthesis is assembly, not adjudication |
| Several agents, overlapping | Two or more agents hold delegation for the same decision | Route only if a precedence rule exists; otherwise escalate before execution |
| No agent in scope | The decision is non-delegable, or nobody was authorized | Do not route — hand to a human |
The question at routing time is not which agent is best placed to answer this. It is which agent is authorized to decide this — and is it only one?
Dimension 2: Autonomy Class, Carried Through Synthesis
AIDRA assigns each agent an autonomy class for the decisions it is cleared to make — from A1 (Execute) through A4 (Recommend). In an orchestrated system, those classes do not disappear at the merge point. They compound.
| Autonomy Class | Definition | What It Means for a Merged Output |
|---|---|---|
| Execute (A1) | Agent decides and acts without notification | A merged output can only execute if every contributing input was A1 |
| Act-and-Report (A2) | Agent acts, decision logged for review | The merged action is logged with every contributing agent named |
| Propose-and-Confirm (A3) | Agent proposes, a human confirms | Any A3 input makes the merged output A3 — a human confirms before it acts |
| Recommend (A4) | Agent recommends, a human decides | Any A4 input means the merged output is advice, not action |
The working principle: a merged output never acts with more freedom than its most restricted input. An orchestrator that combines an A3 security recommendation with an A1 deployment action and then executes the result has quietly upgraded the security agent's autonomy — without anyone deciding it should.
Dimension 3: Escalation Protocol, at the Merge Point
This is the dimension orchestration adds that single-agent AIDRA did not need. When two in-scope agents disagree, there must be a resolution path that was decided before the conflict, not improvised during it.
Pattern 1: Precedence Rule
For predictable conflicts, a written rule decides. One domain outranks another by design: a security flag blocks a code change, a failed test blocks a promotion, reliability outranks cost for customer-facing services. The orchestrator applies the rule. It does not reason about it.
Pattern 2: Named Human
For conflicts no rule covers, the orchestrator escalates to a specific, named person — not a channel, not whoever is on call. The escalation target is part of the orchestration's configuration, the same way the agents themselves are.
Either way, the conflict and its resolution are written to the Agent Decision Log (ADL). Over time, the ADL shows which conflicts recur — and recurring conflicts are the ones worth converting from Pattern 2 into Pattern 1.
The Orchestration Decision Matrix
An illustrative example of what this looks like when written down:
| Conflict at the Merge Point | Precedence Rule | Merged Output's Autonomy | Escalation Owner |
|---|---|---|---|
| Security agent flags a change the code-generation agent produced | Security flag outranks by design | A3 — Propose + Confirm | Tech Lead |
| Two research agents return contradictory facts for one report | None — both shown with sources | A4 — Recommend | Report owner |
| Cost agent and reliability agent disagree on an infrastructure change | Reliability outranks for customer-facing services | A3 — Propose + Confirm | Platform Lead |
| Test agent fails a build the deployment agent wants to promote | Test result blocks by design | A2 for non-prod, A3 for prod | Release owner |
Every row answers the question before it is asked. None of it depends on how persuasive either agent's output happens to sound to the orchestrator on the day.
How the Three Dimensions Work at the Orchestrator
%% caption: AIDRA at the orchestrator: scope checked at routing, autonomy carried through synthesis, escalation at the merge point
flowchart TD
T[Task Received] --> S{Delegation Scope Check}
S -- "No agent in scope" --> H[Hand to Human\nNot Routed]
S -- "Overlap, no precedence rule" --> X[Escalate Before Execution]
S -- "Clear scope" --> R[Route to Agents\nin Parallel]
R --> A[Agents Execute\nWithin Autonomy Class]
A --> M{Outputs Conflict?}
M -- "No" --> Y[Assemble Output\nMost Restrictive Autonomy Applies]
M -- "Yes" --> E{Escalation Protocol}
E -- "Precedence Rule Exists" --> P[Apply Rule]
E -- "No Rule" --> N[Named Human Decides]
P --> Y
N --> Y
Y --> L[Logged in ADL]
What Breaks Without It
When an orchestrated system runs without decision rights at the merge point:
Synthesis becomes adjudication. The orchestrator resolves conflicts by picking, blending, or guessing — and nobody can say afterwards why one agent's output won. The decision exists in the result but not in any record.
Overlap goes undetected until it collides. Two agents hold scope over the same decision and nobody notices, because in testing they happened to agree. The overlap surfaces the first time they don't — usually in production.
Autonomy upgrades silently. A cautious agent's recommendation gets merged into an action that executes. The cautious agent's autonomy class was respected individually and ignored collectively.
Escalation scales with agents, not with risk. Every new agent adds new pairs of agents that can disagree. Without precedence rules, every one of those conflicts lands on the same human. The supervision load grows with the architecture instead of with the stakes.
When decision rights are enforced at the orchestrator instead: overlap is caught before execution, merged outputs carry the right level of autonomy, predictable conflicts resolve by rule, and the human in the loop sees only the conflicts that actually need judgment.
Implementation Guide (30–60 Days)
This does not require rebuilding the orchestration layer. It requires writing down what the orchestrator is already deciding implicitly.
Phase 1: Map the Orchestration Topology (Weeks 1–2)
Objective: For one orchestrated workflow, list every agent, the decisions each one makes, and every point where two agents' outputs are combined.
Mark where two agents hold scope over the same decision. Those are the merge points where the orchestrator is currently adjudicating without a rule.
Deliverable: A topology map showing each agent's decision scope and each merge point.
Success Metric: At least one overlapping scope identified that nobody had documented.
Phase 2: Assign Scope, Autonomy, and Precedence (Weeks 3–4)
Objective: For each agent, confirm its Delegation Scope and Autonomy Class. For each merge point, write the precedence rule — or, where no rule fits, name the escalation owner.
Deliverable: The Orchestration Decision Matrix for this workflow, filled in with real conflicts and real names, not placeholders.
Success Metric: Every merge point has either a written precedence rule or a named human, and every merged output has an explicit autonomy class.
Phase 3: Enforce and Log at the Merge Point (Weeks 5–8)
Objective: Move the matrix out of the document and into the orchestrator's configuration. Overlap without precedence blocks routing. Merged outputs inherit the most restrictive autonomy class. Every conflict and its resolution is written to the ADL.
Deliverable: An orchestrator that applies decision rights rather than inferring them.
Success Metric: At least one real conflict resolved by a precedence rule, and at least one escalated to a named owner — both logged, neither absorbed silently.
Evidence from Practice
This pattern has not been run with a client under this exact name yet — so rather than invent a story, here is what the public evidence on orchestrated systems already shows.
The pattern works, at scale. Anthropic's 2026 Agentic Coding Trends Report documents organizations getting measurable results from it. Fountain's hierarchical multi-agent setup, with a central orchestration agent, delivered 50% faster screening and 40% quicker onboarding. TELUS teams built more than 13,000 custom AI solutions, shipped engineering code 30% faster, and saved over 500,000 hours. Orchestration is not the problem. It is the reason this question now matters.
Delegation still has a ceiling. The same report found that while developers use AI in roughly 60% of their work, they can "fully delegate" only 0–20% of tasks. The rest is supervision. Adding agents in parallel does not lift that ceiling on its own — it multiplies the number of outputs that need supervising. The only lever that shrinks supervision without reducing safety is deciding in advance which conflicts need a human and which can be resolved by rule.
Human judgment stays central. Across every implementation the report describes, human oversight remains part of the design rather than a phase to be automated away. That is AIDRA's starting assumption too. The question was never whether humans stay in the loop. It is whether they are in the loop for the right decisions — or for all of them, because nobody wrote down which ones.
None of these sources describe the merge-point problem in AIDRA's terms. But the shape underneath is consistent: orchestration multiplies what agents can do, and the authority structure has to keep up with it, or a human ends up absorbing the gap.
Action Plan
This Week
Ask three questions about the orchestrated systems you already run:
- For each orchestrated workflow, can you list every decision that more than one agent is authorized to make?
- When two agents' outputs conflict today, can anyone say — without reading the orchestrator's prompt — what happens?
- Has the orchestrator ever executed a merged output that included a recommendation from an agent that was not allowed to act on its own?
If the second question produces silence, your orchestrator is already the attending physician. Nobody appointed it.
Next 30 Days
Pick the orchestrated workflow with the highest consequence if two agents disagree and the wrong one wins. Map its merge points. Write a precedence rule or name an escalation owner for each one. Put it where the team that runs the system will actually see it.
3–6 Months
Make the Orchestration Decision Matrix a condition of adding any new agent to an orchestrated workflow. Every new agent creates new pairs that can conflict — the matrix is where those pairs get resolved before they reach production. Review it on the same cadence as the rest of your architecture governance, not as a separate exercise.
Final Thought
The ward coordinator is essential. Without one, specialists double-book, notes go missing, and the patient waits. Nobody would argue for removing the coordinator.
But no hospital would let the coordinator decide which specialist is right — not because the coordinator is incapable, but because that authority was assigned to someone else on admission.
Multi-agent orchestration has given most organizations an excellent coordinator. What it has not given them is the attending. And as more specialized agents get added to the same workflow, the number of disagreements the coordinator is quietly settling only grows.
The fix is not a smarter orchestrator. It is a written answer, decided in advance, for every place two agents can disagree.
Put Authority at the Merge Point Before the Next Agent Ships
If your orchestrated systems combine agent outputs without a written rule for who wins — that is not an AI capability problem. It is a decision rights gap sitting at the exact point where your agents meet.
or
Routing work between agents is not deciding between them.
