## TL;DR
A bad merge is irreversible context destruction: two customers' issues become one ticket and untangling them is manual. Gate merges hard: require high similarity evidence (same requester, same issue, overlapping time), verify programmatically before merging, and put agent-proposed merges behind human approval until the accuracy rate earns autonomy. Merging is the one ticket action that should default to asking.

## The query

```text
agent merged two unrelated tickets: merge guardrails
```

## Use this when

- Agents merge unrelated tickets
- Merges destroy ticket context
- You are building merge automation
- Auditing merge accuracy

## Not for

- Manual merge best practices
- Splitting merged tickets
- Overall dedup strategy
- Merge UI design

## Steps

### 1. Require multiple independent merge signals

A merge needs at least two of: same requester, same issue signature, close in time, explicit customer reference ("my other ticket"). One signal is a hint; two are evidence. Single-signal merges are where the bad ones come from.

Expected output: multi-signal merge criteria enforced.

### 2. Verify similarity programmatically before proposing

Score the pair: requester match, subject similarity, temporal proximity, shared identifiers. Below the threshold, no merge is even proposed. The score turns "looks related" into a number with a cutoff.

Expected output: a similarity score with a merge threshold.

### 3. Put agent merges behind human approval

Until the merge accuracy rate is proven high over a large sample, every agent-proposed merge waits for a human click. Merges are destructive; the approval gate is proportional to the blast radius. Earn autonomy with data.

Expected output: human approval on all agent-proposed merges.

### 4. Make merges reversible where the platform allows

Prefer merge implementations that preserve the source tickets' history (linked, not deleted). When the platform supports non-destructive merge, use it: reversibility converts a bad merge from a disaster into a correction.

Expected output: non-destructive merge configuration.

### 5. Audit merge accuracy and tune the threshold

Sample merged pairs and judge correctness. Track the accuracy rate; tune the similarity threshold and signal weights from the misses. The audit is what eventually justifies removing the approval gate.

Expected output: merge accuracy tracking driving threshold tuning.

## Template: the checklist

```text
Merge guardrails:
[ ] Multi-signal criteria (2+ independent signals)
[ ] Programmatic similarity score with threshold
[ ] Human approval on agent-proposed merges
[ ] Non-destructive merge where supported
[ ] Accuracy audits tuning the threshold
```

## Variant phrasings

### agent merged wrong tickets

Steps 1 and 3. Signals plus approval gate.

### unrelated tickets merged automatically

Steps 2 and 3. Score threshold plus human gate.

### bad ticket merge by ai

Steps 3 through 5. Approval, reversibility, audits.

## Why it happens

Merging feels like tidiness: fewer tickets, cleaner queues. Agents optimize for tidiness and merge on weak evidence (similar subjects, same week). But tickets are customers' issues, and two similar-looking issues from two customers are not one issue. The agent sees text similarity; it does not see the two humans behind the text. Guardrails supply the skepticism the model lacks.

## Edge cases

- The customer asks to merge: explicit customer request is the strongest signal. Still verify the tickets are theirs.
- Merging into the wrong survivor: the surviving ticket should be the one with the most context, not just the oldest. Choose deliberately.
- Merge chains: A merged into B, then B merged into C. Chains compound errors; audit chains with extra skepticism.
- Platform merge limits: some platforms restrict merge direction or count. Know the constraints before automating.

## Provenance

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