Scheduled Automation principles
Scheduled Automation “starts an ordinary root Agent Run on a schedule.” It reuses the same models, context, Tools, Skills, MCP connections, approvals, and usage pipeline. It is not a separate background Agent with greater capabilities.
Tasks and Runs
- A Scheduled Automation Task is the long-lived configuration: task description, target, model, permissions, schedule, and notification policy.
- A Scheduled Automation Run is one execution, triggered by a scheduled time, Run now, or startup recovery.
Editing a Task does not rewrite a Run that is already queued or active. Each Run stores a snapshot of its configuration when it enters the queue, so historical results remain associated with the settings used at that time.
How scheduling works
While the application is running, the Core Server periodically checks for due tasks and adds eligible work to the queue. It is not an operating-system scheduler: after the application exits, no background process wakes at the scheduled time.
On the next startup, if several schedule points were missed while offline, the system merges them into one recovery Run. This preserves ongoing tracking without launching a large amount of stale work at once. Scheduled Automation is therefore appropriate for periodic checks, but not for billing, trading, or alerting infrastructure in which no scheduled point may ever be missed.
The target determines where results go
- New chat: Every Run creates a new root conversation.
- Existing chat: Every Run appends a turn to the selected active root conversation.
If the project, model, or chat becomes invalid, the task enters Needs repair instead of silently switching to another target. Scheduled Automation cannot bind directly to a subagent conversation, but the root Agent can use Multi-Agent during a Run.
Why permissions are frozen
When a Task is saved, the system resolves Default, Full, or Custom mode into specific permissions. Future Runs use this snapshot so an older task does not accidentally receive new capabilities after global settings become broader.
The current global toggle remains an upper bound for revocation. Disabling Full or Custom mode can block corresponding tasks from entering execution. Re-enabling the mode does not automatically broaden or repair an old task; the user must edit and confirm it.
When a background Run encounters an action that requires approval, it stops at Waiting for approval. Scheduled tasks are not a way to bypass human approval.
Status, Attention, and notifications
A task has an Enabled or Paused scheduling state and a separate health status. A Run progresses through queued, starting, running, waiting-for-approval, and terminal states. The system also stores Attention markers for failures, important updates, invalid configuration, and similar conditions.
Native system notifications are only entry-point reminders. They may be hidden by system settings and have a very small window in which a duplicate can appear. Confirm the final facts in the run history and corresponding chat. Marking an Attention item as resolved does not change the Task or Run.
Appropriate and inappropriate current use cases
- Appropriate: daily reports, project inspections, periodic information tracking, and recurring organization.
- Inappropriate: tasks that must run on time while the application is closed, one-time reminders, complex cron schedules, or critical infrastructure that cannot tolerate duplicates or missed runs.
For operating steps, see Create a scheduled automation.