Scheduled Tasks

What belongs in a scheduled job

Anything that repeats and is not worth manually triggering every time is a good candidate, such as:

• checking a source for new material
• triggering a recurring research or assistant turn
• delivering results to the app or a channel at a fixed time

Four decisions to make when creating a job

1. Trigger style

• every for interval-based runs
• cron for expression-based schedules
• at for one-off timed execution

2. Session target

• main when the job should continue inside an existing context
• isolated when the job needs a cleaner boundary

3. Payload type

• systemEvent for more system-oriented behavior
• agentTurn when the schedule should trigger an actual assistant turn

4. Delivery path

• none when the result only needs to stay in records
• announce for in-app or channel delivery
• webhook for external systems

Where to inspect runtime state

The scheduling surface is already an operations view. In practice, you should look at:

• Overview for totals, next wake, and recent activity
• List for current job definitions and status
• Records for specific runs, stages, and errors

When a job “seems not to work,” that is usually the first place to inspect before changing the workflow itself.

How to keep automation stable

• start with low-frequency, low-risk jobs
• make inputs and outputs explicit
• keep a failure delivery path where it matters
• review recent errors and consecutive failures regularly