Decision Intelligence

Multi-agent systems, when decisions genuinely conflict

Several agents optimising separately will reach incompatible conclusions. The design question is not how they cooperate, but who resolves it when they do not.

Multi-agent systems: bu ne anlama geliyor

Multi-agent systems: from data through prediction to a recorded decision

Multi-agent architectures are usually presented through cooperation: agents specialise, share context, and together cover more than one could. The interesting part is what happens when they disagree.

An inventory agent minimising holding cost and a service agent maximising fill rate will reach opposite conclusions about the same SKU. Both are correct within their objective. Neither is wrong in a way more data would fix.

Conflict is a design output, not a defect

If two agents never disagree, either their objectives are the same — in which case one agent would do — or one is not really deciding anything.

Genuine specialisation produces genuine conflict. A system that hides it has usually resolved it silently, by ordering, by timing, or by whichever agent writes last.

Three ways it gets resolved, only one of them deliberate

By precedence. One agent’s output overwrites another’s. Fast, and invisible: nobody can tell later that a conflict existed.

By aggregation. Outputs are averaged or weighted. This produces a number neither agent would have chosen and neither can defend — the midpoint between “order 400” and “order 0” is rarely the right answer.

By an explicit arbiter. A rule, a threshold, or a person, applied to a conflict that is recorded as a conflict. Slower, and the only one that can be audited.

What the arbiter needs

Not more model output. It needs each agent to state its objective, its recommendation, and what it would cost to accept the other one.

“Service agent: order 400, expected stockout risk drops from 12% to 3%. Inventory agent: order 150, holding cost 8,000 lower over the horizon.” That is a decision a human can make in ten seconds, and a rule can make consistently.

Two confidence scores are not that.

Escalation thresholds belong to the business

Most conflicts should not reach a person. The question is which ones.

Value at stake is the usual axis, and the usual mistake. A small conflict repeated four hundred times a week matters more than one large conflict a quarter. The threshold worth setting is on the pattern, not only the instance.

Where multi-agent designs actually earn their cost

Not in accuracy. A single well-specified model usually matches a multi-agent system on any one metric.

They earn it where the objectives genuinely belong to different parts of the business, and the trade-off between them is a decision someone is accountable for. Then separating the agents makes that trade-off visible and assignable, instead of burying it inside one loss function that nobody outside the data team can read.

If the trade-off does not need to be visible, the extra architecture is buying complexity and nothing else.

The failure mode to watch

Agents that agree suspiciously often. It usually means they share an input that dominates both, and the specialisation is nominal. Two agents reading the same forecast will agree about the forecast, whatever their objectives say.

Conflict rate is worth monitoring for the same reason override rate is: near zero is not a success signal, it is a sign that nothing is being tested.

Request a Demo