Deduplication looks like the safest job to hand an agent: find two requests that mean the same thing and merge them. It is the one that goes wrong with the most confidence, because "the same request" is a judgement call, not a string comparison, and an agent's tone does not change when the judgement is wrong.
This page is one part of a larger loop. For the whole thing end to end, see running support with a coding agent.
Why doesn't the same wording mean the same request?
Two customers asking for "dark mode" can be asking for entirely different things: one means the app's own colour theme, the other means an exported PDF that stops arriving on a white background. The words match. The requests do not. An agent scoring similarity on text alone will rate that pair a near-perfect match, because the words genuinely are near-identical, and matching words is precisely what it is built to notice first.
Why is the reverse failure worse, different words for the same problem?
This is the miss nobody notices. Two requests using entirely different language for the same underlying problem look unrelated to a text match, and unless someone reads both closely enough to see the shared cause, they stay two open items indefinitely, each collecting its own small trickle of votes and comments that should have been one larger, more persuasive request. A wrongly merged pair is visible, and someone can un-merge it. An unmerged pair that should have been one request is invisible, because nothing about it looks broken. It just quietly understates how many people actually want the thing.
When is a narrower request not a duplicate at all?
A parent request and a genuinely narrower special case are not the same thing, even when the narrower one reads as a subset of the first. "Export to PDF" and "export to PDF with the original page numbers preserved" overlap, but the second carries a constraint the first does not, and that constraint is usually the interesting part: the reason the general version was not good enough for that customer. Merge the two and the constraint disappears into a broader request nobody built to actually satisfy it.
What does a merge actually destroy?
Votes and comments attached to the item being merged away do not always travel cleanly to the surviving one. Comment context written against the original wording can read strangely once it is sitting under a different title, and the person who wrote the original request may never see it again. Canny.io says so on its own help page:
Merging a post does not send any user notifications
Canny.io, Merging and unmerging posts
A merge that looks tidy from the roadmap side can look like a request vanishing, from theirs.
Why doesn't an agent's confidence track whether it's right?
This is the part that actually matters. An agent merging two genuinely identical requests and an agent merging two unrelated ones produces output in exactly the same tone: certain, fluent, unhedged. Nothing in how the answer is phrased tells you which one you are looking at, because the system generating both is doing the same thing either way, producing the most plausible-sounding conclusion available to it. A person making the same call at least has a felt sense of when they are guessing. An unsupervised merge has no equivalent signal, which is the whole reason it needs a person on the other side of it before anything actually merges.
| Failure mode | What it looks like | Why it matters |
|---|---|---|
| Same words, different problems | Two requests using identical language for unrelated things | A high text-similarity score with nothing underneath it |
| Different words, same problem | Two requests that never get compared, because nothing about them looks alike | The miss nobody notices, because it never looks like an error |
| Parent and special case | A narrower request folded into a broader one | The constraint that made it interesting disappears |
| Merging away the evidence | Votes and comments losing their original context | The person who wrote it stops seeing their own words |
| Confidence without calibration | A wrong merge stated in the same tone as a right one | Nothing in the output tells a reviewer which is which |
What actually works instead of trusting the merge?
Four habits, none of them complicated.
Propose, do not merge. An agent that flags a likely duplicate for review has done something useful. An agent that merges it unilaterally has made a decision that should have belonged to whoever reads the board.
Make it state the reason in one sentence. "These look like the same request because..." forces the agent to produce something a person can actually check, which is faster and more reliable than re-deriving the judgement from scratch. Checking a stated reason is a different task from making the original call, and a much easier one.
Keep every merge reversible. A merge that can be undone in one step costs little when it is wrong. A merge that silently discards the original title, votes and comments costs a great deal, and the difference is entirely in how the merge was built, not in how confident the agent sounded when it made it.
Review the merges nobody flagged, not only the ones somebody proposed. The unmerged pair from the second failure mode above never generates a prompt asking anyone to look at it, which is exactly what makes it dangerous. An occasional pass looking for requests that read like they belong together, rather than only checking the ones the agent already suggested, is the only way to catch that one.
One payment, no subscription, unlimited products.
This is the same discipline letting an agent answer without letting it invent applies to replies: a single source of truth, review before anything becomes final, and treating a confident answer as no more trustworthy on its own than an unconfident one. The support inbox as a git repository is what makes "propose, do not merge" practical rather than aspirational, since a proposed merge is just a diff sitting unmerged until someone reads it.
Frequently asked questions
Should an agent ever merge two requests without review?
No. Flagging a likely duplicate for a person to check is useful. Merging it unilaterally removes a judgement call that should have belonged to whoever reads the board.
What is the single biggest risk in automated deduplication?
Confidence that does not track accuracy. A wrong merge and a right one are stated in exactly the same tone, so nothing in the agent's output tells a reviewer which one they are looking at.
How do you catch a duplicate the agent never flagged?
By occasionally reviewing requests that look like they might belong together, rather than only checking what has already been proposed. An unmerged pair that should be one request never generates a prompt asking anyone to look at it, which is what makes it the dangerous case.
Is a narrower request always safe to merge into a broader one?
No. A special case often carries the constraint that made the original request interesting, and folding it into a general item loses that detail entirely.
What happens to votes and comments when two requests merge?
They should travel with the merge, but not always cleanly. Comment context written against the original wording can read strangely under a new title, which is exactly why keeping every merge reversible matters: it limits the damage when something does not travel well.