A small online shop automates its customer support with three AI modules: one replies to customers, one tracks order progress, and one decides on refunds. One day a customer writes, “The item arrived broken, I want a refund.” All three modules wake up at once. The support module replies, “We’ve arranged your refund.” The progress module sets the order status to “Processing.” The refund module decides a photo is missing, sets the status to “Waiting for documents,” and sends another email asking for a photo. The customer gets two emails that contradict each other, and where the order status ends up depends on which module wrote last.
“Module” here goes by different names in different tools: skills, agents, automations. What they share is that they take over a piece of work automatically when an event happens.
Faced with this kind of conflict, many teams first think of adding arbitration rules to decide who wins. The more effective fix is to go back to the design: one entry point per event, only one module allowed to write each field that gets changed, and the other modules only offering suggestions.
Why arbitration rules keep piling up
Arbitration rules sound reasonable: the refund module’s decision outranks the support module’s, and the progress module writes last. But as the rules multiply, you have to handle exceptions between them. If the refund module hasn’t finished, should the support module wait? If two modules write almost at the same moment, which one counts as first? Every new rule cleans up after a competition that shouldn’t have happened.
An even more common approach is “last write wins,” because it requires no design at all. The problem is that the last writer isn’t necessarily right. It was just slower.
Conflicts come from two places
The first source is duplicate triggers. The same thing arrives through several doors: the customer’s email triggers once, the support system creating a ticket triggers again, and a schedule that scans unhandled cases every five minutes triggers a third time. The three entry points have different names but handle the same thing. Many “modules fighting each other” are actually one module being called three times.
The second source is multiple writers. All three modules are allowed to change the order status field. As soon as two or more modules can write the same field, conflict is only a matter of time.
Both sources come from design, not from how smart the model is. Microsoft’s architecture guide to multi-agent orchestration patterns cautions against running agents simultaneously on the same task when they can’t reliably coordinate changes to shared state or external systems. It also suggests that if a single agent with tools can handle the task reliably, that simpler approach should come first. Anthropic’s article on building agents gives similar advice: find the simplest solution possible, and add complexity only when it demonstrably improves outcomes.
One entry point, one writer
So conflicts should be fixed at the source, in this order.
First, give each event one entry point. List every source that triggers a module, find the ones with different names that handle the same thing, and merge them. When the same event is sent again, the system has to recognize it. This is mature practice in payment systems: Stripe lets each request carry a unique identifier, an idempotency key, so when the same request is resent, the system returns the first result instead of doing the work again. AI module events can follow suit: give each event an ID and process each ID only once.
Next, give each field one writer. List the fields that get changed and mark the ones where a mistake is costly: order status, refund amount, emails to customers. For each of these, keep only one module that can write. The others can read and suggest, but not change it directly.
Finally, turn the race into a relay. Back to the shop: the refund module becomes the main module. It decides, writes the order status, and determines whether to send an email. The support and progress modules pass what they see to the refund module. The customer gets one email, and the order status has one source.
Arbitration still has a role, but only for exceptions
Some cases genuinely can’t be separated in the short term, such as a legacy system that’s hard to change, or two departments each owning part of the same field. Arbitration is still needed there, but treat it as an exception: write the priority order clearly, stop and hand over to a person when it can’t decide, and record every time arbitration is used. The number of times it’s used shows where the design still isn’t fixed.
This approach has a cost too. Keeping only one writer means that when the main module fails, no other module can automatically step in. So the main module’s failures need to be detected and passed to a person, rather than letting other modules scramble to take over.
As a next step, pick the event that causes trouble most often and ask two questions. How many entry points does it come through? For each field it changes, how many modules can write? If both answers are “one,” this event hardly needs arbitration. If your AI modules come from third parties, there’s another layer to check before installing them; see An AI Agent Extension That Passed the Scan Still Isn’t Safe to Install, Because the Risk Shows Up When It Runs. For cleaning up when a process fails halfway, see When Automation Stops Halfway, Find Out What Already Happened Before Rerunning
AI handoff card
Ask AI to find an event’s entry points and writers This prompt asks which event wakes several modules, lists its entry points and the writers of each field, and suggests how to switch to one main module that writes.
In my automation, one event wakes several AI modules (skills, agents, or automations) at once, and they often conflict.
The method comes from this article: https://boosterminiclass.com/en/posts/ai-agent-skill-conflict-prevention/
Its view: conflicts mainly come from two places, the same event arriving through several entry points, and several modules being able to write the same field. The fix is one entry point per event and one writer per important field, with other modules only making suggestions; arbitration is kept for exceptions that can't be separated.
Ask me 3 questions first:
1. Which event is it, which modules does it wake, and what does each do?
2. Which sources does the event come through (for example an incoming email, a new ticket, a scheduled scan), and can the same event be triggered more than once?
3. Which fields or outward actions do these modules change (for example order status, amounts, sending emails), and how many modules can write each one directly today?
Based on my answers, give me:
- An entry-point list: which entry points actually handle the same thing, how to merge them, and how to recognize repeated events;
- A writer list: the current writers of each important field, and the single writer to keep;
- The process as a relay: which module is the main one and what the others pass to it;
- The exceptions that still can't be separated and need arbitration or a person's judgment.
Don't assume my system has features I haven't mentioned. If information is missing, ask me first.
The suggestion is only a starting point. Which module becomes the writer is up to the person responsible for the process.
References
- Microsoft Learn (Azure Architecture Center): AI Agent Orchestration Patterns — https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns [accessed: 2026-10-11]
- Anthropic Engineering: Building effective agents — https://www.anthropic.com/engineering/building-effective-agents (2024-12-19)
- Stripe Docs: Idempotent requests — https://docs.stripe.com/api/idempotent_requests [accessed: 2026-10-11]
