Schedules

An agent whose trigger is scheduled / autonomous can carry one or more schedules: recurring runs the platform executes for it. You declare when the agent should run and what each run should do; the platform owns the timer and invokes the agent on schedule — the agent itself needs no scheduling code, no extra permissions, and no extra network access.

What a schedule declares

Each schedule on an agent has:

• id — a unique name for the schedule (unique within the agent).
• cron — when to run (see the accepted forms below).
• task — a natural-language instruction dispatched to the agent on each run, exactly as if a person had asked it ("check the status page and summarize any incidents").
• channel / channel_target (optional) — deliver the run's result to a channel, for example a Slack channel the agent is connected to.

Schedules only apply to autonomous agents. On a human-triggered agent they would never fire, so they are dropped at create and cleared if the agent is switched to human-triggered on a skill edit.

Accepted cron forms

The cron field is validated when the agent is created or updated, so a bad expression fails fast instead of silently never firing:

• A standard 5-field cron expression — minute, hour, day-of-month, month, day-of-week — with *, numbers, ranges (a-b), steps (*/n, a-b/n), and comma lists, each within its field's bounds.
• The shortcuts @hourly, @daily (or @midnight), @weekly, @monthly, and @yearly (or @annually).

@every <duration> intervals are not supported — use a 5-field expression or one of the shortcuts.

How schedules run

The platform materializes the agent's schedules whenever the agent is deployed, and reconciles them on every redeploy — schedules added, changed, or removed on the agent take effect with the next deploy. On each tick the platform invokes the agent with the schedule's task, authenticated the same way as any other platform call; the run then appears like any other execution, with its events on the agent's Activity tab.

If schedule setup can't complete during a deploy, the agent itself still deploys — the deploy logs a warning and the next redeploy retries the schedules.

Declaring schedules

Schedules are part of the agent's configuration payload: they are declared in the schedules list of the create request, and updated when a skill edit is applied. The console's create flow sets the scheduled / autonomous trigger but does not yet expose a schedule editor — declare schedules through the platform API for now.

CI-deployed agents are different: their repository owns scheduling (the runtime configuration baked into the image), so the platform does not manage schedules for them.