The demonstration that every enterprise vendor is now giving involves several agents. A procurement agent spots a shortage and sources it. A finance agent checks budget and terms. An operations agent confirms the receiving window. They negotiate, converge, and produce a purchase order without anyone touching a screen. It is the most compelling thing in enterprise software right now, and it is also the point at which a reasonable person should ask who, exactly, is accountable for the outcome.
One agent acting within limits is a control problem you can solve. Three agents agreeing with each other is a control problem where the evidence of the decision is a conversation nobody read
That distinction is the whole of the governance question, and it is worth being precise about before the pilots start.
What multi-agent actually buys you
There is a genuine architectural argument, and it is not about intelligence. It is about scope. A single agent given procurement, finance and operations responsibilities needs every permission, every data source and every rule in one place, and it becomes untestable. Several narrow agents, each with a bounded remit and a bounded permission set, are individually verifiable. That is a real benefit and it mirrors how you would organise people. The problem is that the analogy holds for the structure and breaks for the accountability.
Where the accountability goes missing
When three people resolve a cross-functional decision, there is a record: someone approved it, their name is on it, and if it was wrong you know who to ask. When three agents resolve it, the record is an exchange of messages between systems, and the question "who decided" has no answer that would satisfy an auditor. Three specific failure modes follow. Diffused responsibility. Each agent acted within its own limits and the aggregate was still wrong. Nobody breached anything. Consensus without judgement. Agents converge quickly, which reads as agreement and is frequently just the absence of anyone raising an objection. Human cross-functional friction is annoying and it catches things. Compounding error. A small mistake in the first agent's premise — a stale lead time, a misread contract term — is treated as established fact by everything downstream. There is no equivalent of a colleague saying "that number looks wrong".
Four things to insist on before any pilot
A single accountable human for the whole chain, not one per agent. The chain is the unit of accountability because the chain is what produces the outcome. A limit on the aggregate, not just the components. Three agents each operating within a modest threshold can commit a large sum between them, and the cap must apply to the result. A readable record of the exchange. Not a system log — a rendered account of what each agent concluded and why, that a controller can read in a minute and an auditor can request. One mandatory human checkpoint at the commitment. For this year, put it where money or a legal obligation leaves the organisation. Everything upstream can be automated.
Bound the roles
Separate procurement, finance and operations permissions and inputs.
Check the chain
Test stale or wrong premises and enforce an aggregate limit.
Retain the reasoning
Preserve intermediate conclusions in a readable decision record.
Approve the commitment
Keep the accountable human checkpoint where money or a legal obligation leaves.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The sequencing that actually works
Automate the sequence before you automate the negotiation. Most of what these demonstrations show is coordination — passing a task along with context attached — rather than genuine multi-party reasoning, and the coordination is where the time savings live. A deterministic workflow with model-driven steps at each stage captures most of the value with a fraction of the governance burden, and it is auditable by construction. Reserve genuine agent-to-agent resolution for cases where the outcome is reversible and the amounts are small.
Practical Guidance for Multi-Agent ERP Design Consultation
- Name one accountable owner for the whole chain.
- Cap the aggregate, not only each agent's threshold.
- Produce a readable decision record, not a system log.
- Keep a human checkpoint at the point of commitment.
- Automate the sequence first, the negotiation later.
- Bound each agent's permissions to its stated remit.
- Test the compounding case — feed a wrong premise and watch what happens.
- Measure how often agents disagree; near-zero disagreement is a warning sign.
The Regional Angle
The first thing worth noting is that the cross-functional friction these systems remove has a specific function in regional organisations, and removing it costs something. In a great many Gulf businesses the informal check on a purchase is that the finance manager knows the supplier, knows the market price, and knows that the last three deliveries from that vendor arrived short. None of that is in the system. An automated chain that consults only recorded data will transact competently with a supplier every experienced person in the building has reservations about. Before automating a category of spend, ask the people currently doing it what they know that the system does not — and if the answer is substantial, write it into the vendor master or keep the human in the loop. The second concerns the commitment point, which regional businesses should place differently than the vendor's reference architecture suggests. Payment practices here involve post-dated cheques, letters of credit, trade finance facilities and bank guarantees, and those instruments carry consequences that are not reversible by cancelling a transaction in the system. A chain that concludes with an instruction touching a bank facility is materially different from one that concludes with an internal order, and the two should not share a control design. Keep the human authorisation at the instrument, not merely at the order, and make sure your treasury team is in the design conversation rather than being told about it afterwards. The third is about evidence and who will ask for it. Regional group audit functions and external auditors are, for the most part, encountering system-initiated cross-functional transactions for the first time, and the practical reality is that an unfamiliar control environment produces scope expansion rather than a considered assessment. The organisations that handle this well produce a short, plain-language document — what the chain does, which agent holds which permission, where the human checkpoint sits, how exceptions are sampled — and walk the audit team through it before the year-end fieldwork. It is an afternoon's work and it changes the audit from an investigation into a review. It also, usefully, forces you to write down a design you may not yet have fully articulated.
The objection worth taking seriously
The strongest objection is that this is a distinction without a difference. A single agent executing a multi-step procurement workflow raises exactly the same questions as three agents doing it in sequence; the number of processes involved is an implementation detail, and dressing it up as a new governance category is consultants inventing a problem. Organisations already have limits, logs and approval points. Applying them to a chain rather than a step is a configuration change, not a new discipline. There is real force in that, and the architectural point is correct: the agent count is indeed an implementation detail. What is not a detail is where the reasoning becomes unobservable. A single agent's decision has one set of inputs and one output, and you can inspect both. A chain's decision has an intermediate layer — the conclusions each agent passed to the next — that exists only in transit and is discarded unless you deliberately capture it. That is why the readable record matters more here than anywhere else, and why aggregate limits matter more than individual ones. The discipline is not new, but the place where it has to be applied has moved, and organisations applying yesterday's control design to this architecture will find they have logs of every action and no record of the decision. The objection is right that the principles are familiar. It is wrong that the existing implementation of them will hold.
Common Questions
Is this different from an orchestrated workflow?
Often not, in practice. Ask the vendor whether the sequence is fixed or determined at runtime, because a fixed sequence with model-driven steps is far easier to control and is what most products actually do.
How do we test a multi-agent chain?
Adversarially. Supply a wrong premise early and observe whether anything downstream questions it. Most chains do not, and knowing that changes where you put the checkpoint.
Should each agent have its own identity?
Yes, with its own permissions and its own log entries. Shared service accounts across agents defeat the entire point of bounding them separately.
What should we expect over the next twelve months?
Expect multi-agent framing in every major vendor's marketing and genuinely runtime-determined coordination in very few products. Expect the first notable incidents to involve aggregate exposure rather than individual errors. Expect audit firms to ask about decision records before they ask about accuracy. And expect the successful deployments to be narrow, reversible and considerably less exciting than the demonstrations.
Multi-Agent ERP Design Consultation — we design the accountability and the decision record before the agents start talking to each other.