Docs / Scheduled tasks / Where results go

Choosing where results go

Every scheduled duty stores a thread mode plus optional source thread (thr_*). Together they decide (1) where the assistant reply is saved in the dashboard, (2) which conversation memory the model reads before acting, and (3) whether you also get notifications on email, WhatsApp, or Telegram. Hub: scheduled tasks.

Three thread modes

• standalone — no linked dashboard thread. Memory and replies live on a synthetic cron_{jobId} row. You mainly see output in the notification inbox (and any external channels you enabled).
• linked_full — post into a chosen thr_* thread and use that thread’s pins and rolling summary as context each run. Default when you schedule from an open chat or hire a Specialist duty.
• linked_fresh — post into a thr_* thread but do not inject that thread’s chat history into the model. Context stays on cron_{jobId} (prior cron turns only). Useful when you want a clean run without long-thread bias; Specialist persona pins still apply on duty threads.

Deleting the linked thread reverts affected jobs to standalone automatically — recreate the link if you still want in-thread history.

What you see in the dashboard

For linked modes, each run adds two compact messages to the target thread: a 🕐 Scheduled run divider and the assistant reply (badged 🕐 Scheduled). The full duty prompt is not repeated in the transcript — only the trigger note and answer — so weekly jobs do not spam identical user lines.

For standalone runs, the prompt and reply are stored on the synthetic cron thread (not your main sidebar list). Check the Schedule notification feed for the human-readable summary.

Files the agent writes during a run are copied into your Files workspace automatically when the run completes — you do not need a separate upload step.

Schedule UI mapping

When creating or editing a task in the dashboard:

• Results → post to a thread — sets linked_full or linked_fresh with a source_thread_id. Pick the thread your team actually monitors.
• Results → notifications only — standalone; use when ops should not clutter a client-facing chat.
• Context each run → use thread memory — linked_full.
• Context each run → fresh — linked_fresh; same delivery thread, isolated context.

Specialist duties on the Team Task Board usually attach to that Specialist’s lane thread. Drag a card to another Specialist to reassign who runs the duty — verify the target thread still matches where you want history.

External delivery (optional)

Beyond the dashboard thread, delivery_prefs can include:

• ui — notification inbox (always useful for standalone tasks).
• email — via configured transactional email when enabled on the host.
• whatsapp / telegram — requires a linked channel and plan send limits (limits FAQ).

Mention the desired channel in the duty prompt when you want a short summary in chat plus a fuller copy elsewhere — e.g. “post a three-line summary here and email the table.”

Practical patterns

• One thread per workflow — competitor monitor, SEO digest, and finance check each get their own thr_* so logs stay contiguous.
• Ops vs client threads — run noisy automation standalone or on an internal ops thread; keep customer-facing threads linked_fresh if you only want deliverables, not full automation context.
• Long outputs — ask the agent to write a dated file under ~/files/ and post a short summary in the linked thread.
• Chains — downstream duties can read files or hand off via next_job_id; align thread targets when the next step expects prior context (chaining tasks).

Related: Cron syntax · Troubleshooting missed runs · Threads & memory · repo docs/scheduledTasks/Readme.md §5 and §11