hermes - 💡(How to fix) Fix [Feature]: Discord cron delivery should optionally create a fresh thread per execution [1 comments, 2 participants]

Problem or Use Case

Cron outputs in Discord are often not just notifications; they are actionable work items.

Today, a cron job can deliver to a Discord channel, or to an already-existing thread, but there is no built-in way to have a scheduled run automatically create a fresh thread for that specific execution and post its output there.

This becomes a real usability problem in shared channels:

• recurring cron jobs can produce long or actionable outputs
• if all scheduled runs post top-level into the parent channel, the channel becomes noisy
• if a user comes back after several days, they may see many cron outputs stacked in the main channel
• only some of those runs may require follow-up, but any discussion about them now has to happen in the same parent channel
• this mixes unrelated follow-up conversations together and makes delayed triage messy

Concrete example:

A user comes back to Discord after 5 days and finds 10 cron outputs in a channel. Only 3 of them actually require action. If those 3 are discussed in the main channel, the follow-up becomes interleaved and hard to track. What would be more useful is for each cron execution to have its own scoped, contained discussion space.

A "thread per run" model would make each scheduled execution:

• scoped and contained
• easier to review later
• easier to action selectively
• less disruptive to the parent channel
• better suited for follow-up discussion tied to that specific run

This seems especially valuable for recurring reports, digests, research summaries, monitoring summaries, wiki maintenance runs, or any scheduled output that may lead to follow-up work.

Proposed Solution

Add an optional Discord cron delivery mode that creates a new thread for each execution when the delivery target is a Discord channel.

Example intent:

• target a normal Discord channel as the delivery destination
• on each cron run, create a fresh thread under that channel
• post the cron output inside that thread instead of directly into the parent channel

Possible configuration shape (or equivalent):

deliver: discord:<CHANNEL_ID>
create_thread_per_run: true
thread_name_template: "wiki-saneamiento — {date}"
thread_auto_archive_duration: 1440

Or an equivalent design such as:

• delivery_mode: direct | thread_per_run
• thread_name_template
• thread_auto_archive_duration

Expected behavior:

1. Cron job resolves a Discord channel target
2. If thread_per_run mode is enabled, Hermes creates a new thread for that execution
3. Hermes posts the scheduled output into that thread
4. The created thread_id is used as the effective delivery destination for that run
5. If Discord requires a seed message for thread creation in some cases, the implementation should keep that minimal and treat the thread as the primary destination

This should be optional and backward-compatible. Existing cron jobs should continue working exactly as they do today unless the new mode is enabled.

Alternatives Considered

1. Deliver directly to the parent channel

This is the current behavior, but it becomes noisy and mixes unrelated follow-up discussions in shared channels.

2. Deliver to one fixed pre-existing thread

This is better than top-level posting, but it still mixes all executions into one long thread. That works for passive logs, but it is much less useful when only some runs need action and discussion.

3. Manually create a thread after each scheduled post

This adds friction and defeats the point of automation. It also makes the workflow inconsistent and easy to neglect.

The "fresh thread per run" option seems like the best fit for scheduled outputs that may become actionable.

Feature Type

Gateway / messaging improvement

Scope

Medium (few files, < 300 lines)

Contribution

• I'd like to implement this myself and submit a PR