ticket dedupe agent merging unrelated threads: undo and guardrails

TL;DR

A dedupe agent that merges unrelated threads is matching too loosely: its similarity threshold is below the ambiguity level of your ticket stream. Raise the threshold so only near-certain duplicates auto-merge, route the middle band to human approval, and build undo as a first-class operation because some bad merges will still happen. Every merge must be reversible and logged.

The query

ticket dedupe agent merging unrelated threads: undo and guardrails

Use this when

• The dedupe agent merges unrelated tickets
• Customers complain their issue got mixed with someone else's
• You are designing dedupe guardrails
• Auditing dedupe agent decisions

Not for

• Building duplicate detection models
• The manual ticket merge UI
• Choosing dedupe algorithms
• Merging companies or users

Steps

1. Freeze auto-merge and assess the damage

Pause automatic merging immediately. List recent merges and sample them for correctness. Know the bad-merge rate before changing anything; you need a baseline to tune against.

Expected output: auto-merge paused, bad-merge rate measured.

2. Raise the similarity threshold for auto-merge

Set auto-merge to fire only above a high similarity threshold tuned on labeled examples. The middle similarity band goes to human approval, never to auto-merge. Precision beats recall here: a missed duplicate is a minor annoyance, a bad merge is a data corruption.

Expected output: threshold set from labeled data, middle band human-approved.

3. Require multi-signal agreement for auto-merge

A single signal (similar subject) is not enough. Require agreement across signals: same requester or company, overlapping time window, similar content. Unrelated threads rarely agree on three signals.

Expected output: auto-merge requires multiple agreeing signals.

4. Build undo as a first-class operation

Every merge must record what moved where so it can be reversed: tickets, comments, attachments, field values. Test the undo path on a real merge before relying on it. A merge without undo is a gamble.

Expected output: tested undo restoring pre-merge state.

5. Log every merge decision with its evidence

Record the ticket pair, the similarity score, the signals that agreed, and whether it was auto or human-approved. The log is your tuning data and your audit trail when a customer asks what happened.

Expected output: a merge decision log with evidence per merge.

Template: the checklist

Dedupe merging unrelated threads:
[ ] Auto-merge paused, bad-merge rate baselined
[ ] Similarity threshold raised, middle band human-approved
[ ] Multi-signal agreement required for auto-merge
[ ] Undo tested and available for every merge
[ ] Decision log with evidence per merge

Variant phrasings

dedupe agent bad merges

Steps 1 and 2. Pause, then raise the threshold.

undo ticket merge

Step 4. Undo as a designed operation.

ticket merge approval workflow

Steps 2 and 3. Threshold bands plus multi-signal.

Why it happens

Dedupe thresholds get set for the average ticket stream, but real streams have clusters of similar-but-distinct tickets: outage reports, release feedback, billing questions. A threshold that is right on average merges the ambiguous cluster constantly. The middle band is where the damage lives, and it needs humans, not a sharper threshold alone.

Edge cases

• Mass incidents: hundreds of genuinely duplicate outage tickets. Temporarily lower the threshold with a human watching, then restore.
• Cross-customer merges: never auto-merge tickets from different companies on subject similarity alone. Require requester or company match.
• Merged ticket chains: A merged into B, then the pair merges into C. Undo must handle chains, not just pairs.
• The human approval queue overflowing: if most candidates need review, the detector is too loose. Tighten candidate generation, not just the threshold.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nHZ2y75Eg8ftDuMQJYuDAQ