Multi-agent conflicts in SAP: loops, clashes and double actions

In 30 seconds

What it is One owner per action, clear precedence, loop limits, safe retries, human escalation.

You use it when Two or more agents can read or change the same customer, supplier, employee or document.

Next in this section Running 10 AI agents across HCM, Finance and Procurement in SAP →

Two agents can each be right and still be wrong together. Give every action one owner, and every clash one human.

Part 25 of 26 in SAP Business AI, Explained.

Two agents can each be right on their own and still be wrong together. Put a collections agent and a customer service agent on the same customer on the same day, and the customer can get a blocked account and a refund promise in the same inbox. So once several AI agents share a customer or document, you have to decide in advance who acts, who waits and when a person steps in. Below are the three ways agents collide and the five rules I use to prevent most of it.

Collisions in a nutshell

Three failure patterns: conflicts (two agents want opposite actions), loops (agents keep undoing each other) and double actions (the same step runs twice).
Five rules prevent most of them: one owner per action, a precedence list, loop limits, idempotent actions and escalation to a named human.
SAP gives you the structure, not the policy. It describes assistants that coordinate agents by role and an agent gateway that governs agent communications and human oversight, but who wins a clash is up to you.

The everyday picture

Think of two departments writing to the same customer. Credit control sends a “your account is on hold” letter and customer service sends “your refund is on its way”. Each is correct by its own rules, and together they embarrass the company.

In this series’ hospital picture, two specialist doctors (agents) prescribe for the same patient, and the ward coordinator (the assistant) notices the clash and calls the consultant before either is given.

How a clash gets caught before it reaches the customer

Name the shared objects that more than one agent can read or change, such as customer account, supplier, employee record or purchase requisition.
Give each action (block, refund, change, create) on each object exactly one owning agent and one owning team. Other agents can propose but never execute.
Send cross-agent work through a coordinator. SAP’s Joule Agents page describes assistants that coordinate agents by role, and that layer can see all proposals on one object before any of them runs.
Detect and stop. The coordinator checks precedence, loop counters and duplicates, and pauses anything outside the rules.
Escalate. A named person sees both proposals side by side and decides, and it’s logged.

Monday morning on account 40017

Two of the ten agents at NextSAP Utilities, the fictional Dubai utility used across this site’s SAP content, meet on one commercial customer: Al Noor Property Management, which pays for many premises through one collective bill account, 40017. The account and the amounts are made up too.

At 07:00 on Monday the collections prioritiser (agent 5, L2 Propose; still at L2 at this point, and post 09 covers its later move to L3) finishes its overnight review of about 2,400 overdue open items. Account 40017 owes AED (UAE dirham) 86,000, and AED 52,000 of that is over 45 days past due. The agent flags the account for a credit block (no new service requests accepted until payment), which Elena’s collections team decides. It never blocks on its own.

At 09:20 the customer emails to dispute an AED 12,400 bill for one of its premises, based on an estimated meter read. The case classification and routing agent (agent 10, L4 Act then report) classifies it as a billing dispute with a refund claim, routes it to the refunds team and sends the standard acknowledgement: “your refund request is being processed”.

At 09:21 NextSAP’s finance assistant, built on the Joule Assistants pattern, sees two open proposals on account 40017. One flags the customer for a block, the other says process a refund. Its rule is that when a block flag and a refund meet on the same account within 72 hours, neither executes, so it escalates to Elena, the collections lead, with both proposals, the open items and the claim.

At 11:00 Elena decides, in five minutes. The AED 12,400 credit note goes ahead once an actual meter read confirms the estimate was too high. The block waits, and the account manager calls the customer to agree a payment date for the remaining AED 39,600 that’s over 45 days.

The pilot, before that rule existed, turned up two other problems.

A loop. Elena’s team had turned down a block flag on another account, and the collections agent flagged it again the next night, and the night after. The fix is a loop limit: after a human override, the agent can’t propose the same action on the same object for 14 days unless the facts change, for example a new overdue item.
A double action. The routing agent timed out on a slow call and retried, creating two refund cases for one claim, worth AED 7,800 each. Idempotency fixes this: each claim carries one request key, and a retry finds the existing case instead of making a new one.

Five rules, side by side

Rule	Prevents	Simple version	NextSAP example
One owner per business action	Conflicts	Only one agent may execute each action on each object	Only collections may flag a block (Elena’s team decides), only refunds may credit
Precedence list	Conflicts	A written order for common clashes	Open complaint or outage case pauses any new block
Loop limits	Loops	Count repeats and stop after a human override	No repeat block for 14 days after override
Idempotency	Double actions	Same request twice, same result once	One request key per claim
Escalation	Everything else	Pause and hand to a named person	Elena decides block versus refund

The test I run in design reviews: for each shared object, can you name the one agent allowed to execute each action, and the one person who breaks a tie? If not, you’re not ready for a second agent on that object.

Coordination has limits too

Good coordination rules stop agents sending a customer opposite messages, turn repeated overrides into a signal to fix the agent instead of a nightly argument, and make retries safe, so a slow system doesn’t double a refund.

But a wrong proposal, coordinated well, is still wrong, and coordination doesn’t replace authorisation, so each agent still gets only the permissions its job needs. Nor does any of this come ready-made. I haven’t found an SAP source that describes automatic business conflict resolution between agents, so you’ll be writing your own precedence list.

Explain it to your CFO

One of our agents once flagged a customer for a block on the same morning another agent promised that customer a refund. Now, when that happens, neither goes ahead until Elena, our collections lead, decides.
And a repeated request can never pay out twice.

Before you add a second agent

Who owns each action on each shared object? The team that owns the business process, as the SAP Community Agent Mesh post also argues: whoever owns the process owns the agent.
What’s your precedence for common clashes? My default: an open complaint or dispute pauses any new block or dunning step on that customer.
How many repeats before a loop stops? I’d allow none after a human override, for 14 days, unless new facts arrive.

Go deeper

Technical detail for architects and developers

SAP’s Joule Agents page describes role-based coordination by assistants, and says prebuilt agents use MCP (Model Context Protocol) and A2A (Agent2Agent). SAP’s Business AI page describes an enterprise agent gateway that applies identity, access and policy at runtime and governs agent communications, tool use and human oversight. Put the conflict check where it sees every proposal on a shared object, in the assistant or orchestration layer, with the gateway enforcing.

For escalation, the A2A specification defines a task lifecycle with states including submitted, working, input-required, completed, failed, canceled and rejected. Input-required is an interrupted state, the task waiting for more input, which fits “paused, waiting for a human decision”. Rejected fits “this agent declines the action”.

On idempotency, the A2A specification says agents can use the message identifier to detect duplicate messages, and that cancelling a task is idempotent. For actions in SAP Cloud ERP, add a business-level key such as the claim number and check for an existing document before creating one. Don’t count on the model remembering it already acted.

OWASP’s LLM06:2025 Excessive Agency describes damage caused by excessive functionality, permissions or autonomy, and recommends human approval for high-impact actions and authorisation checks in downstream systems. A collections agent that could block on its own, with no coordinator check, would be a small case of excessive autonomy.

The SAP Community Agent Mesh post recommends that each agent states what it may execute, when it escalates and what a rollback looks like. Record those boundaries with the agent in SAP AI Agent Hub, which, per SAP’s documentation, gives every governed agent a defined owner and governance status.

Words you’ll hear

Coordinator: the layer, often an assistant, that sees what several agents propose and decides what goes ahead.
Precedence: a written order for which action wins when two clash.
Loop: agents, or an agent and a human, undoing each other’s work again and again.
Idempotency: making a repeated request have the same effect as a single one.
Escalation: pausing work and handing the decision to a named person.
Agent2Agent (A2A): an open protocol for agents to hand tasks to each other, like a formal handover note between departments.
Excessive agency: an agent with more tools, permissions or freedom than its job needs.

Keep going

Independent explainer, not affiliated with or endorsed by SAP SE. SAP, Joule and other SAP product names are trademarks of SAP SE.

Frequently asked questions

Does SAP resolve conflicts between agents automatically?

I haven't found an SAP source that describes automatic conflict resolution between agents. SAP describes assistants that coordinate agents by role and an agent gateway that governs agent communications and human oversight. The conflict rules themselves are yours to design.

What is idempotency, in plain words?

It means doing the same request twice has the same effect as doing it once. A retried refund request should find the first refund, not create a second one.

Which agent should win in a conflict?

Neither, by default. I'd write a precedence list for common cases and name a human for everything else, especially where money or a customer promise is involved.

Does the A2A protocol help?

Yes, for structure. The A2A specification defines tasks with states, including one where the agent needs more input, and allows agents to use a message identifier to detect duplicates. It does not decide business precedence for you.