agent merged two unrelated tickets: merge guardrails

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

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

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