## 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

```text
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

```text
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