Twelve agents, one answer
Multi-agent systems fail in a specific way: two agents answer the same question differently and the system picks one silently. The interesting engineering is not the routing — it is what happens when they disagree.
What it is, and what it is not
A router with an ownership model. Each agent owns a domain — structures, change, the item master, the traversal, supply, quality, compliance, cost — and a question is routed to the owner rather than to whichever agent was asked.
It is not a committee. Agents do not vote, and answers are not blended. Blending two answers produces a third that neither agent would defend and that nobody can trace to a source, which is the opposite of what the citation model exists to provide.
It is also not a planner that decomposes arbitrary goals. The set of agents is fixed, their domains are declared, and their hand-offs are typed. An orchestrator free to invent workflows is one whose behaviour cannot be reviewed before it runs.
The mechanism: typed hand-offs, explicit precedence
A hand-off is a typed request between agents, not a conversation. The Digital Thread Agent asking the BOM Agent which products contain a part sends a structured request and receives a structured result — no free text in between, because free text between agents is where meaning quietly changes.
When two agents produce conflicting answers, three rules decide, in order. First: a deterministic service outranks any agent. If impact analysis says four products and an agent says three, the service wins, and the discrepancy is reported rather than hidden.
Second: the domain owner outranks a visitor. The BOM Agent's answer about a structure beats the Cost Agent's incidental claim about the same structure, because one of them owns that domain and the other was passing through.
Third: unresolved means abstain and escalate. If neither rule settles it, the orchestrator reports that two agents disagree, shows both answers with their citations, and asks a person. It does not average, and it does not pick the more confident-sounding one.
The failure it prevents
An engineer asks what a change will cost. The Cost Agent answers by rolling up a structure it resolved for itself, and returns a number. The BOM Agent, asked separately about the same change, reports a different set of affected lines.
Both answers are fluent, both are cited, and they are inconsistent. In a system without precedence the user sees whichever they asked for, and the two never meet — until somebody notices in a review that the cost figure was computed over a line set that does not match the impact analysis.
The damage is not the wrong number. It is that a user who catches one inconsistency stops trusting every answer the system gives, including the correct ones. Precedence exists so that inconsistency surfaces as an explicit disagreement rather than as two confident answers in different tabs.
How it meets the rest of the product
Every agent calls the same domain services the interface calls, so the deterministic layer underneath is shared. That is what makes the first precedence rule meaningful: when a service and an agent disagree, the service is not a competing opinion — it is the thing the agent was supposed to be reading.
Permission tiers are enforced per agent per tool, and a hand-off does not escalate privilege. An agent at Observe that hands off to an agent at Prepare does not thereby cause a write on the first agent's behalf; the receiving agent's tier applies to its own actions, and the acting user's permissions bound both.
Citations survive hand-offs. A four-hop answer names the objects and revisions read at each hop, including the ones read by an agent the user never addressed. An answer that lost its provenance crossing an agent boundary would be worse than no orchestration at all.
Every hop lands in the hash-chained audit trail, so the record shows which agents participated, at which tiers, and what each contributed — rather than a single row saying the assistant answered.
How it meets your ERP
The system-of-record matrix is orchestration-wide rather than per agent. An agent handing work to another cannot route around a field's ownership: if cost is ERP-mastered, no chain of hand-offs produces an agent permitted to write it.
That matters because privilege escalation through delegation is the obvious hole in any multi-agent design. Here the constraint is enforced at the tool layer beneath every agent, so it holds regardless of which agent asked which.
ERP-sourced values keep their provenance across hand-offs too. A cost figure that reached an answer via three agents still carries its source system and as-of stamp, and is still visibly weaker evidence than a resolution Manufacturing PLM can reproduce.
Where the boundary is
It does not add capability. The orchestrator routes and reconciles; it cannot do anything an individual agent could not, and it holds no tools of its own. A user who disables every agent has disabled the orchestrator too.
It also does not resolve genuine ambiguity in a question. Asked something that spans domains with no clear owner, it will say so and ask rather than choosing a domain and answering confidently within it — which is the failure mode that makes multi-agent systems feel unpredictable.
Facts
| Model | Ownership and routing — not a vote, not a blend |
| Hand-offs | Typed requests, never free text between agents |
| Precedence 1 | A deterministic service outranks any agent |
| Precedence 2 | The domain owner outranks a visitor |
| Precedence 3 | Unresolved → abstain, show both, escalate |
| Privilege | A hand-off never escalates — tiers apply per agent |
| Citations | Survive every hop, including agents you did not address |
| Own tools | None — it adds no capability of its own |
Frequently asked
What happens when two agents disagree?
Three rules, in order: a deterministic service outranks any agent; the domain owner outranks a visitor; and if neither settles it, the orchestrator abstains, shows both answers with their citations and asks a person. It never averages or picks the more confident one.
Do agents vote on an answer?
No, and blending would be worse than choosing. A blended answer is one neither agent would defend and that cannot be traced to a source, which defeats the citation model. Ownership decides who answers, and disagreement is surfaced rather than smoothed away.
Can a hand-off escalate permissions?
No. Tiers are enforced per agent per tool at the layer beneath every agent, so an Observe-tier agent handing off does not cause a write on its behalf. The acting user's own permissions bound the whole chain regardless of how many agents participate.
Do citations survive multiple hops?
Yes. A four-hop answer names the objects and revisions read at each hop, including by agents you never addressed directly. An answer that lost its provenance crossing an agent boundary would be considerably worse than having no orchestration at all.
Can it plan arbitrary multi-step work?
No. The agent set is fixed, domains are declared and hand-offs are typed. An orchestrator free to invent its own workflows is one whose behaviour cannot be reviewed before it runs, which is exactly the property that makes multi-agent systems feel unpredictable.
Does the orchestrator have its own tools?
None at all. It routes and reconciles, and cannot do anything an individual agent could not already do on its own. Disabling every agent disables the orchestrator along with them, because there is nothing left underneath it to route any work to in the first place.
What if a question has no clear owner?
It says so and asks. Choosing a domain and answering confidently within it is the behaviour that erodes trust fastest, because the answer is not wrong so much as scoped to a question the user did not ask and has no way to notice.