Results Delivered to the Right Channel
19.6. Results Delivered to the Right Channel — Getting Output Where It Belongs
Why this is a problem you have to think about, not something that is right by default
With an agent operating across multiple platforms at once, getting a task’s result (a report, a file, a notification) to the right channel — instead of getting stuck in a CLI session nobody is watching, or landing in the wrong channel for the wrong recipient — requires active configuration, not a “it will be fine” default.
Delivery targets for cron jobs
As already stated in 17.4, each cron job has its own report delivery target (Telegram, Discord, Slack, Signal, or a local file) — declared explicitly when the job is created, never inferred implicitly from context.
Background tasks also need an explicit target
With /background, the task runs in a separate session, fully detached from the current session’s history — the result does not automatically “flow back” to the chat session you have open; if you want a notification when it completes instead of having to come back and check yourself, you need to configure the receiving end explicitly.
Channel overrides also affect the “voice” where results appear
Combined with channel_overrides (7.3): a channel can have its own system_prompt that shapes how results are presented — meaning the same task, delivered to #support and to #research, can be phrased differently to suit the readers.
Notes
- For every important cron job or background task, always declare the delivery target explicitly — never rely on the default, because the default is usually the place nobody monitors most often.
- If a report “vanishes” after running, the first thing to check is that job’s delivery target configuration, before wondering whether the job ran at all.
- For teams using many channels for many purposes, consider a clear naming convention for delivery targets (for example, always naming a job after the channel that receives it) — it reduces confusion when several cron jobs run in parallel.