Scheduling Workflows and Conversations
Workflows and conversations both support scheduling. Once you set a schedule, the platform runs the work at the right time, in the right timezone, and routes the result to your Inbox so you find out without checking.
What you can schedule
- A workflow — a published workflow runs end-to-end on its schedule, with inputs you specify upfront
- A conversation — a recurring conversation kicks off with a starter prompt; useful for things like daily standup digests or weekly research briefs
Cron and timezones
Schedules use standard cron expressions plus a timezone. Common examples:
0 9 * * 1-5 — every weekday at 9:00 AM
0 15 * * 5 — every Friday at 3:00 PM
0 6 1 * * — first day of every month at 6:00 AM
*/30 * * * * — every 30 minutes (use sparingly)
The timezone you pick determines what "9:00 AM" means. If you're in Singapore and you set 0 9 * * 1-5 with Asia/Singapore, the workflow runs at 9 AM SGT regardless of where the platform is hosted.
Schedule-aware agents
Agents that participate in a scheduled workflow know they're running on a schedule. They have access to:
- The schedule definition — so an agent can say "this is the weekly Friday report" in its output
- The previous run — agents can reference what happened last time, useful for change tracking and "what's new since last week" framing
- The next scheduled run — handy for setting expectations in the output
This means a scheduled "weekly report" agent can naturally write "This is the report for the week of May 22–28. Last week's totals were X; this week is Y, a change of Z."
What lands in the Inbox
When a scheduled run finishes, the platform writes to your Inbox:
- A summary line ("Weekly status — completed in 47s, saved 1 file")
- A link to the run's output
- A link to the conversation or Library item if one was produced
- An error notice if any step failed
You can opt in or out per schedule. By default, runs that touch your Library or send external messages notify you; pure read-only runs stay quiet unless something fails.
Best practices
- Test the workflow manually first — never put an unverified workflow on a schedule
- Pick a timezone that matches the audience — if the output is for a global team, prefer UTC; if it's for your local team, pick the local zone
- Watch the first scheduled run — the second one usually behaves the same as the first, so getting the first one right matters
- Use the Inbox to triage — clear notifications as you go, so the Inbox stays a useful "needs attention" list rather than a wall of noise