Schedules

One fire, one fresh session

A schedule carries a cron expression, a timezone and a prompt. On each fire the platform starts a new agent session and sends that prompt as the first message. There is no carry-over from the previous run, so the prompt has to be the whole task: state the job, not a follow-up.

The expression is the standard five field form (minute, hour, day-of-month, month, day-of-week) and is read in the schedule’s IANA timezone, which defaults to UTC. Minute resolution is as fine as it goes: anything sub-minute is rejected. For example, */15 * * * * fires every 15 minutes, 0 9 * * 1-5 at 09:00 on weekdays, and 0 0 1 * * at midnight on the first of the month.

The platform checks for due schedules once a minute, which is why a minute is the floor. A due schedule comes off the due list the moment it is picked up and gets its next run time before its session starts, so the next check cannot fire it a second time.

From the dashboard or from an MCP client

Schedules are authored on the agent, not on the workspace list. Open the agent in the dashboard and use its Schedules card, or call agnt_schedules_create from a connected MCP client.

You can also ask the Agnt Wizard to add, change or delete one. A schedule is a record of its own, not part of the agent’s config, so the Wizard writes it directly instead of staging a proposal for you to approve.

agnt_schedules_create({
  agent_id: "<deployed agent uuid>",
  name: "Morning pipeline review",
  cron_expression: "0 9 * * 1-5",
  timezone: "Europe/Berlin",
  input_text: "Review every deal that moved yesterday and post a summary."
})

Toggle it, or fire it by hand

The workspace Schedules page lists every schedule in the workspace with its next run, a calendar view of what fired when, and two controls per row: an enabled toggle and a run-now button that dispatches immediately without touching the timetable. Pausing leaves the schedule and its history intact, so it is the right way to stop something temporarily.

Deleting is not reversible from the MCP surface. When you only want it to stop, disable it instead.

Every fire lands in the run log

Each fire writes one trigger run, recorded as dispatched, failed or skipped, and the agent’s Runs view lists them with the schedule name attached. Each row deep-links to the read-only transcript of the session that ran, which is where you go when a scheduled job produced the wrong answer.

A skipped fire opens no session, so it has no transcript. Its reason, and a failed fire’s error, show in the Detail column of the Recent runs list on the workspace Schedules page and of the Run history on the schedule’s own page. A fire is skipped while the agent is a draft or disabled, while a blocking config request it raised is open, or while the plan or an empty AI credit balance pauses it. A failure leaves the timetable as it was, except on an archived agent, whose next fire fails and switches the schedule off. What each status means is on sessions and runs.

A scheduled run has no interactive caller, so anything the agent needs a human for goes out of band: approvals and questions are delivered to the agent’s configured chat reach, fall back to the workspace’s default Slack channel, and are always visible in the dashboard’s approvals panel even when no channel is configured.

Four tools

Whether a past run actually fired is a separate question from what the schedule says, so check the trigger runs rather than the schedule row when something looks missing. From an MCP client that is agnt_observability_list_trigger_runs, in the observability family, which is enabled independently of these four.