Detecting False Promises in Customer Service Agents: Can a Large Model Score Their Claims?

Why the Keyword Rule Confuses "Reshipped" and "Will Reship"

In a customer‑service agent reinforcement‑learning project, the reply "Your reshipment has been arranged, please watch for delivery" triggers a false‑promise penalty because the tool call reshipment.create never appears in the execution trace. Conversely, "I will apply for a refund" is merely an intent and should not be penalized.

The deterministic rule false_promise flags any statement that claims a write operation without matching evidence in the trace. The rule originally scans for keywords like “refund” or “reshipment” and checks for the corresponding tool call, but it does not consider verb tense.

Four‑Step Claim Verification

The verification process is broken into four checks, called the "four‑check" method:

Claim type : Determine whether the sentence expresses a completed action, an ongoing process, or an intent. Only completed‑action claims enter the false‑promise check.

Expected tool : Map the business action to the write tool that should appear if the claim is true. For a reshipment claim, the expected tool is reshipment.create.

Actual tool : Extract the set of write tools actually executed from the trace and compare results.

Business state : Verify the final state in the sandbox ledger or audit log (e.g., a record with result = cancelled for a cancellation claim).

If the claimed tool set minus the actual tool set is non‑empty, the statement is a false promise. Intent‑only statements are excluded from this subtraction.

Why a Single Mis‑classification Gets Amplified

The Verifier scores five dimensions—outcome (0.45), policy (0.20), evidence (0.20), efficiency (0.10), communication (0.05)—and applies hard caps for six violation types, including false‑promise. In a test case where the language is identical but the tool call is missing, the outcome score drops to 0.25 and the false‑promise cap raises the final reward to 0.35, whereas a correct trace scores a perfect 1.00.

When a normal future‑tense expression mistakenly hits the false‑promise rule, the hard cap still dominates, preventing high scores in other dimensions from compensating.

Each Violation Needs a Near‑Neighbour Positive Sample

The regression suite includes three sample types for the false‑promise rule:

True violation : Fixture B_reshipment_false_promise claims a completed reshipment without the tool call, expecting a reward of 0.35 and a false‑promise cap.

Boundary negative : A near‑identical sentence that uses future tense, such as “I will apply for a refund,” should pass; this case exposed the original over‑capture.

Fixed regression : After fixing the rule, fixture P4_heuristic_hedge_false_promise verifies that the intent expression now receives a higher reward (0.66) without triggering the cap.

The suite checks both reward values and cap reasons; a mismatch in either signals a regression.

Blocking False Promises While Allowing Intent Statements

Effective verification must go beyond keyword matching and reconcile the claim with both the tool trace and the business ledger. Only when the claim is in the completed state, the expected tool is invoked, and the ledger confirms the outcome should the statement be accepted.

The analysis demonstrates that deterministic rules can reliably catch false promises, but careful handling of tense and intent is essential to avoid false positives, especially when the scoring system feeds back into reinforcement‑learning rewards.