Picture a stainless steel water bottle that your enterprise resource planning (ERP) system lists at 380 grams and your supplier portal lists at 4,560. An AI agent preparing a retailer feed reads both values, picks one, and publishes it. Nothing in the feed shows the choice, and the retailer's shipping estimate reflects it weeks later.

A conflict rule settles that choice in advance. It tells the agent which source wins, how large a difference matters, when to stop, and what to record.

In Brief

• An AI agent that finds two values for one attribute has to write one of them, and without a rule you cannot see which one it chose.
• A conflict rule has four parts: source priority for each attribute, a tolerance, a stop condition, and a decision log.
• Master data management settles most conflicts upstream, and the conflict rule covers the ones that surface when the agent acts.
• The rule lives in a versioned lookup that the agent calls before it writes a value.
• Replaying past conflicts through the rule shows how often the agent would stop and whether that rate is workable.
• Two named signers and a review date keep the rule accurate as your sources change.

Why Conflicting Master Data Is Different for an AI Agent

Conflicting master data is different for an AI agent because a person who sees two values stops to ask, while an agent has to return an answer and therefore writes one of them.

Think about the last time you caught a mismatch in a product record. You saw two weights, sensed something was off, and walked over to the person who owns the supplier data. That small pause protected your catalog for years, and nobody wrote it into a process because nobody needed to.

Hand the same task to an AI agent and the pause disappears. The agent reads both values and returns one, because the task requires an answer. The record goes out either way, and nothing in the output tells you that two values existed or which one won.

Gartner's AI-ready data research shows what is at stake across a whole portfolio. Gartner predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data, and it describes AI-ready data as data representative of the use case, including its errors and outliers. Two records that disagree are one example of such an error, and your use case decides what the disagreement costs.

The pattern shows up again in Gartner's agentic AI forecast. Gartner expects organizations to cancel more than 40% of agentic AI projects by the end of 2027, and it names escalating costs, unclear business value, and inadequate risk controls as the reasons. Every conflict an agent resolves without a rule is a small gap in risk control that nobody sees.

Where a human checkpoint disappears from a workflow is a broader question that a readiness assessment answers. The question here is narrower, and it is the one you will face on the day the agent goes live. What should the agent do at the moment two records disagree?

The Four Kinds of Master Data Conflict an AI Agent Faces

An AI agent meets four kinds of master data conflict, and each one calls for a slightly different answer in your rule.

• Two values for one attribute. The ERP says 380 grams and the supplier portal says 384 for the same bottle.
• A stale value against a current one. The supplier revised the specification last month, and only one of your systems received the change.
• Two records for one entity. The same supplier appears twice under slightly different names, each with its own payment terms.
• One field with two meanings. The ERP stores the weight of one bottle, while the supplier portal stores the weight of a case of twelve.

You have probably seen all four in your own data. The first two ask which value is right, while the third asks whether two records describe the same thing and the fourth asks whether the two values measure the same thing. A rule that covers only the first two leaves the other two to the agent's judgment.

The Four Parts of a Conflict Rule for AI Agents

A conflict rule for an AI agent has four parts: source priority for each attribute, a tolerance, a stop condition, and a decision log. Together they answer the four questions the agent cannot answer for itself. Which value should it trust, how much disagreement should it accept, when should it stop, and what should it leave behind for you?

Source Priority for Each Attribute in a Conflict Rule

Source priority names, attribute by attribute, which system wins when two values disagree.

Ranking whole systems feels simpler, and it breaks the moment one system is authoritative for one attribute and weak for another. Your ERP may hold the best logistics data and the thinnest marketing copy, while the supplier portal may hold the reverse. A single ranking forces one of them to lose on attributes where it should win.

For each attribute, write down three things:

• the source that owns the attribute
• the fallback source when the owner has no value
• the tie-break between two values of equal rank, usually the most recent update

Start with the attributes your agent writes most often. A priority list for twenty attributes that carry real consequences serves you better than a list of two hundred that nobody reviews.

The Tolerance Before a Difference Counts as a Conflict

Tolerance is the size of difference below which the agent treats two values as the same and moves on.

Weights of 380 and 384 grams disagree on paper without needing a person, while 380 and 4,560 deserve attention before anything reaches a retailer. The tolerance is the line between those two situations, and without it the agent has no way to tell a rounding difference from a real one.

Set tolerance for each attribute, because a one percent gap on weight and a one percent gap on a regulated specification carry different risks. Most rules settle on three bands:

• a gap small enough to resolve by source priority without comment
• a middle gap resolved by source priority and flagged in the decision log
• a gap large enough to stop the agent

Each business sets its own band edges. Text attributes need an equivalent test, such as whether two descriptions state the same specification.

The Stop Condition That Sends a Conflict to a Person

A stop condition is the circumstance in which the AI agent writes nothing and hands the conflict to a person.

McKinsey's agentic AI playbook lists defining triggers for escalations as part of governing agents, and your conflict rule is where those triggers become specific.

MIT Sloan's AI Decision Matrix, developed by researchers at MIT CISR, gives you a way to choose them. It rates a decision on ambiguity, meaning how clearly the data determines the answer, and on risk, meaning the cost of a wrong decision and how easily a person can reverse it.

Two disagreeing sources raise ambiguity by definition, so your task is to score the risk. A wrong shipping weight on a low-cost accessory corrects itself in the next feed. A wrong value on a compliance attribute reaches a retailer and sometimes a regulator. One of the companies in the MIT Sloan article requires a person for every pricing decision, because an inaccurate price is a constraint it will not trade away. Your rule can draw the same kind of line for the attributes where an error costs you most.

Four triggers cover most catalogs:

• any conflict above the top tolerance band
• any conflict on an attribute your business marks as always reviewed, such as price, compliance, or safety data
• any conflict of the third or fourth kind, meaning two records for one entity or one field with two meanings
• any conflict the agent cannot match to a row in the rule

A stop condition works only when a named person receives the stopped conflict. Write down who that is for each group of attributes, how quickly they must answer, and what the agent does in the meantime, which is usually to leave the last published value in place. When the person answers, the answer goes back into the rule as a new row or a changed priority, so the same conflict does not stop the agent twice.

The Decision Log for Each Resolved Conflict

The decision log records, for every conflict the AI agent resolves, which values it saw, which rule row it applied, and which value it wrote.

The same McKinsey playbook asks for traceability mechanisms from the outset, and it warns that low-quality data silently affects decisions across agents. The log is how you make that silent effect visible in your own catalog. Five fields are enough:

• the entity and the attribute
• the values and sources the agent saw
• the rule row and the version it applied
• the value it wrote, with the time
• whether a person took part

With these fields, the question "why does the retailer have this weight?" becomes a lookup and stops being an investigation. A monthly read of the log also shows you which rows fire most often and which attributes keep stopping the agent, and that tells you where your upstream data needs work.

Conflict Rules Versus Match and Merge Rules

A conflict rule differs from the match and merge rules inside a master data hub because it governs the moment an AI agent acts on records, while match and merge rules govern how the hub builds them.

Survivorship is the rule inside a master data hub that decides which value survives when records for the same entity merge into one. If you run a hub, it already settles many conflicts before an agent ever sees them, and the golden record, the single trusted version of each record, carries the survivors. The conflict rule starts from those survivorship rules and does not replace them.

Conflicts still reach the agent for three reasons:

• the agent reads a source that never passed through the hub, such as a supplier portal
• the survivorship rules cover some attributes and leave others open
• the hub holds a value that is older than the latest change in a source system

If you do not run a hub yet, the conflict rule is the first place these decisions get written down. That makes it a useful early step toward one, and the written priorities carry over when the hub arrives.

Where a Conflict Rule Lives for an AI Agent

A conflict rule lives in a versioned lookup table that the AI agent calls before it writes a value.

Pasted into a prompt, a rule reads like advice, while a table lets you test it row by row, version it, and have the data owners review it. A paragraph of instructions supports none of that. The table needs one row for each attribute, with columns for the owning source, the fallback source, the tie-break, the tolerance bands, the stop flag, the receiver, the version, and the review date.

Every log entry names the version of the table it applied. That lets you answer a retailer's question about a value written in March with the rule as it stood in March, and it shows exactly which change to the table altered the agent's behavior.

A One-Page Conflict Rule Template

Copy this template for each attribute group, and fill in every blank before the agent receives write access.

• Attribute and kind of conflict covered: ________
• Owning source: ________
• Fallback source: ________
• Tie-break: ________
• Band 1, resolve quietly: gap up to ________
• Band 2, resolve and flag: gap from ________ to ________
• Band 3, stop: gap above ________
• Always reviewed: yes or no
• Receiver of a stopped conflict: ________
• Response time: ________
• Value held while waiting: ________
• Rule version and review date: ________
• Signed by (data owner and business owner): ________

A Worked Example of an AI Agent Resolving One Product Weight

Say you run product data for a consumer brand that sells stainless steel water bottles through retailers, and an AI agent prepares the weekly retailer feed. Your rule for shipping weight, written with the template above, has these entries. The figures here are illustrative, and your own bands depend on your products and your retailers.

• Owning source: the ERP logistics record
• Fallback source: the supplier portal
• Tie-break: the most recent update
• Band 1: a gap up to 2%, resolved quietly
• Band 2: a gap from 2% to 10%, resolved and flagged
• Band 3: a gap above 10%, stop
• Receiver: the logistics data steward, the person who maintains that data, who answers within two working days
• Value held while waiting: the last published weight
• Rule version: 12

The agent meets three bottles in the same feed.

Bottle A. The ERP says 450 grams and the portal says 454. The gap is about 0.9%, which falls in Band 1. The ERP owns the attribute, so the agent writes 450 and logs the conflict as resolved quietly.

Bottle B. The ERP says 620 grams and the portal says 660. The gap is about 6.5%, which falls in Band 2. The ERP still wins, the agent writes 620, and the log entry carries a flag. At the weekly read, the steward sees that the supplier switched to a heavier lid ahead of your ERP and asks the buyer to refresh the ERP record.

Bottle C. The ERP says 380 grams and the portal says 4,560. The portal value is twelve times the ERP value, far past the 10% line for Band 3, and it matches the fourth kind of conflict. The agent writes nothing, keeps the last published weight, and sends the conflict to the logistics steward with both values and both sources.

The steward divides 4,560 by 380 and gets exactly 12. The portal lists the weight of a case of twelve, and the ERP lists the weight of one bottle. The steward adds a row to the rule stating that this supplier's portal weight is a case weight, which the agent must divide by the pack quantity before it compares the two values. The table moves to version 13.

The next feed contains the same bottle. The agent applies version 13, converts the portal weight to 380 grams, finds no gap, and resolves it in Band 1 without involving anyone. The log shows when the row changed and who made the change, which is the answer you need if a retailer ever asks about the weight published in the earlier feed.

Without the rule, the agent chooses between 380 and 4,560 with nothing to guide it, and the wrong choice reaches the retailer. With the rule, the worst outcome is a short delay on one product.

Testing a Conflict Rule Before an AI Agent Uses It

Test a conflict rule by replaying conflicts your team already resolved and checking what the rule would have done.

Replay Past Conflicts Through the Rule

Gather a set of conflicts from sources you already have, such as retailer feed rejections, steward queue history, and reconciliation spreadsheets. Run each one through the rule and compare the rule's answer with the decision your team made at the time.

Every mismatch points to a row that needs work. Some mismatches expose a priority set in the wrong order, and others expose a kind of conflict the rule did not anticipate, like the case weight in the example above.

Read the Stop Rate

Count how many of the replayed conflicts the rule would send to a person. That count is your stop rate, and both extremes carry information.

If the rule stops most conflicts, your steward becomes the bottleneck the agent exists to remove, and the bands or the upstream data need attention. If it stops almost none, check that the bands are not wide enough to hide real problems.

Sign Off the Rule

Two roles sign the rule. The domain data owner answers for the source values and confirms the priorities. The business owner of the output, such as the head of ecommerce for retailer feeds, confirms which attributes always go to a person, because that owner pays for a wrong value.

Write the date of the next review beside both signatures. A rule without signers and a review date has no one to correct it when a source changes.

Keeping a Conflict Rule Current

A conflict rule stays current through a review date on every row, a monthly read of the decision log, and a short list of events that trigger an early review.

The values in your sources keep moving, a pattern covered in depth in the post on AI-ready product data drift, and the rule has to move with them. These events call for an early review:

• a new source system joins the feed
• a new supplier portal uses different units or field meanings
• a retailer adds or changes a required attribute
• a row stops the agent repeatedly
• the stop rate shifts sharply from one month to the next

Read the log monthly at first, then quarterly once the stop rate settles. Each read should end with one of two outcomes: the rule stays as it is, or a named person changes a specific row and the version number increases.

Signs a Conflict Rule Is Not Ready

A conflict rule is not ready when it shows any of these signs:

• Priority ranks whole systems, with no attribute-level exceptions.
• Tolerance is missing, so every difference counts as a conflict or none does.
• The stop condition has no named receiver.
• The rule lives in a document or a prompt that nobody tests.
• The log records the written value and omits the values it replaced.
• Nobody signed the rule, and no review date exists.

If you recognize two or more of these, hold the agent's write access until you fix them. In the meantime, let the agent propose values for a person to approve, which gives you the same speed on the easy conflicts and keeps a person in front of the hard ones.

Key Takeaways

• When two records disagree, an AI agent writes a value, so a rule has to make the choice before the agent runs.
• A conflict rule combines source priority for each attribute, a tolerance, a stop condition, and a decision log.
• Source priority works attribute by attribute, because most systems own some attributes and lack authority over the rest.
• A stop condition needs a named receiver and a held value, and the receiver's answer returns to the rule as a new row.
• The rule belongs in a versioned lookup, and replaying past conflicts through it shows the stop rate before go-live.
• A data owner and a business owner sign the rule, and a review date on every row keeps it accurate.