How to Set Confidence Thresholds for AI Agent Actions

A confidence score tells an agent how likely a value is correct. It doesn't say what the agent may do with it. Here's how to turn confidence into a permission model.

Claro published confidence scoreAI agentsdata validationwrite-backproduct data governance

Direct answer: A confidence score answers how likely is this correct? A threshold policy answers what is the system allowed to do about it? Those are different questions, and most catalog teams only have an answer to the first. The fix is a permission model: map each data state — identity resolved, evidence complete, conflict present, action risk — to one of five outcomes: execute, write with flag, recommend, request evidence, or block.

Every team that has switched on automated enrichment or matching hits the same wall around week three. The model returns 0.94 on a match. Somebody asks whether 0.94 is good enough to write to the ERP. Nobody can answer, because 0.94 is a statement about likelihood and the question is about consequence. Claro handles this as a policy layer on top of matching and validation: nothing writes back without a confidence score, provenance, and a rule that says what that combination permits. This playbook is how to build that rule set for your own catalog.

Confidence tells the system how sure it is. Policy tells it what it’s allowed to do. Automating product and supplier data safely requires both — and they are not the same number.

Step 1 — Separate the four inputs

A single score collapses information you need to keep apart. Break every decision into four dimensions:

Dimension Question Example of low state
Identity confidence Is this the same real product or supplier? Two rows share a description, with no MPN or GTIN on either
Evidence quality Where did the value come from? Attribute extracted from a supplier PDF, with no second source
Conflict Do sources disagree? Manufacturer datasheet says IP66; supplier file says IP65
Action risk What happens if this is wrong? Writing a safety rating versus writing a marketing description

A 0.94 match on a low-risk descriptive field and a 0.94 match on a certification field are not the same decision. Treat them differently or you will eventually write a wrong compliance value with high confidence.

Step 2 — Define the permission ladder

Five outcomes. Nothing between them.

Data state Permitted action
Identity resolved + authoritative evidence + low-risk action Auto-execute. Write back, no review.
Identity resolved + single-source evidence + low-risk action Write with flag. Written, marked for sampling.
Strong match + incomplete secondary evidence Recommend. Draft the record, hold for approval.
Material conflict between sources Request evidence. Route back to the supplier or the authoritative source.
Missing mandatory evidence, or safety/compliance-sensitive field Block. No write, regardless of score.

The last row is the one to enforce hardest. Some fields should never auto-write no matter how confident the system is — hazard classifications, certification status, dangerous-goods flags, and anything that a purchase or shipment legally depends on. Confidence is not authority.

Step 3 — Classify your fields by risk before touching thresholds

Do this on a spreadsheet, once, with the category manager in the room. Every attribute in your schema goes into one of three tiers.

  • Tier A — cosmetic. Long description, marketing copy, secondary images. Wrong is embarrassing. Auto-execute at moderate confidence.
  • Tier B — operational. Dimensions, weight, UOM, packaging quantity, category assignment, price tier. Wrong breaks quotes, shipping costs, and search. Requires resolved identity plus a corroborating source.
  • Tier C — controlled. Certifications, compliance declarations, safety ratings, hazard data, country of origin, and anything referenced in a contract or regulation. Human approval or authoritative-source-only, always.

This exercise often reveals that many attributes are Tier A and can move automatically. That is where the time savings live. Measure your own field-tier split rather than relying on a generic benchmark.

Step 4 — Set thresholds from your own error data, not from a default

Do not pick 0.90 because it looks like a reasonable number. Calibrate:

  1. Take a sample of at least 300 automated decisions across a representative supplier mix.
  2. Have a human adjudicate them blind — correct, incorrect, or ambiguous.
  3. Plot error rate against confidence, in bands.
  4. Find the band where your error rate crosses your tolerance for that field tier. That is your threshold for that tier.
  5. Repeat separately for high-variance suppliers. A supplier who sends clean structured feeds and a supplier who sends scanned PDFs will not share a calibration curve.

Set a different threshold per field tier and per source quality. One global threshold is how teams end up simultaneously over-blocking clean data and under-blocking messy data.

Step 5 — Make every automated decision reversible and auditable

Non-negotiable before you increase automation:

  • Every write records: previous value, new value, source, confidence, rule that permitted it, and timestamp.
  • Every write is reversible to the previous value.
  • Every blocked or held item enters a review queue with the reason, not a generic error.
  • Review outcomes feed back into calibration.

If you cannot answer “why did the system write that value on 14 August?” in under a minute, you do not have a permission model. You have a batch job with a score attached.

Step 6 — Widen the gate deliberately

Start narrow. One supplier, one category, Tier A fields only, write-with-flag rather than auto-execute. Sample the flagged writes weekly. When the error rate on a tier holds under tolerance for four consecutive weeks, promote that tier from “recommend” to “write with flag,” or from “write with flag” to “auto-execute.” Never promote two tiers at once, and never promote Tier C.

Before and after

Without a permission model With one
“Is 0.94 good enough?” — nobody knows Threshold per field tier, calibrated on measured error
One global cutoff Different gates for cosmetic, operational, and controlled fields
Conflicts silently resolved by recency Conflicts routed for evidence; decision recorded
Review queue = everything the model wasn't sure about Review queue = decisions that actually need judgment
Compliance fields auto-written at high confidence Compliance fields structurally blocked from auto-write
Automation expanded by feel Automation expanded on four weeks of clean error data

Common failure modes

A single global threshold. Guarantees you are too strict somewhere and too loose somewhere else.

Confidence without provenance. A high score on a value with one unverified source is a confident guess.

No block list. If every field is theoretically auto-writable at a high enough score, controlled fields will eventually auto-write.

Review queues nobody drains. A queue with 4,000 items is a block list you did not intend to create. Size the gates to the review capacity you actually have.

Calibrating once. Suppliers change formats, categories expand, and models change. Recalibrate quarterly and after any supplier onboarding wave.

Run this on your own data

Claro applies this model as standard: identity resolution first, then validation with provenance and confidence, then write-back governed by rules you set per field tier — and continuous monitoring so the decisions stay valid as supplier files change.

Send us one supplier file and the catalog it is about to enter. We will show you where the matches are safe to auto-write, where they need evidence, and which fields should never write without a human — using your data, not a demo set.

Get a free catalog audit →

FAQ

What confidence threshold should I use for automated product matching?

There is no universal number. Calibrate per field risk tier and per source quality: sample at least 300 automated decisions, have a human adjudicate them, plot error rate by confidence band, and set the threshold where error rate crosses your tolerance for that tier. Cosmetic fields tolerate a lower gate than operational fields; controlled fields should not auto-write at any score.

What is the difference between a confidence score and a permission model?

A confidence score estimates how likely a value or match is correct. A permission model maps data states — identity confidence, evidence quality, conflict, action risk — to what the system may do: execute, write with flag, recommend, request evidence, or block. Confidence is an input to the permission model, not a substitute for it.

Which product data fields should never be written automatically?

Fields where an error carries legal, safety or contractual consequence: certifications, compliance declarations, hazard and dangerous-goods data, safety ratings, country of origin, and any attribute referenced in a supply contract or regulation. These should require an authoritative source or human approval regardless of confidence.

How do I know when to increase automation?

Promote one field tier at a time, and only after the measured error rate for that tier has stayed within tolerance for four consecutive weeks of sampled review. Never promote controlled fields.

Claro

See where your catalog breaks — free

Claro runs this automatically: resolve identity, fill missing attributes, validate updates, and write clean records back into your PIM/ERP. Upload a sample supplier file for a free catalog audit.

Get a free catalog audit