Skip to main content
POST
JavaScript
A schedule owns the timer so you do not have to. Each fire creates an objective on the agent, with the message and prompt data you set here. Only spec.schedule is required, and inside it, timezone plus at least one rule.
Only published agents fire. A schedule on a draft agent records a skip instead of creating an objective, and unpublishing an agent pauses its schedules. The schedule still reads STATE_ACTIVE, so a silent lack of runs usually means the agent is not published.

Two kinds of rule

A schedule holds up to 16 calendars and up to 16 intervals, and it fires whenever any of them matches. timezone is required and applies to both. Calendar rules fire at wall-clock times. Each field takes a list of ranges, and the fire times are the cartesian product across fields.
Interval rules fire every fixed duration from a stable anchor, with an optional offset to phase-shift within the period.
That fires at fifteen minutes past every hour. The minimum every is one minute (60s); anything shorter is a 400. The offset must be less than every.

The empty-field rule that catches everyone

Calendar fields do not all default the same way, and this is the one thing to get right:
  • Leave second, minute, or hour empty and it means zero, the top of that unit.
  • Leave dayOfMonth, month, or dayOfWeek empty and it means any.
So the preceding example pins hour and minute to fire once at 9:00. Drop the minute and it still fires once, at 9:00, because an empty minute means zero, not “every minute.” Drop the hour and you get midnight, not hourly. A Range is { start, end, step }. end defaults to start, and step defaults to 1. So { "start": 0, "end": 23, "step": 2 } on hour is every other hour, and { "start": 9 } means 9 o’clock and nothing else. dayOfWeek runs 0 to 6 from Sunday, which makes { "start": 1, "end": 5 } Monday through Friday.

What a fire creates

Each fire calls create-objective on your behalf, carrying the schedule’s fields across:
When the agent declares a systemPromptDataSchema, the schedule’s systemPromptData must satisfy it. A schedule that omits it fails validation on every fire, from inside the worker. Nothing surfaces on the schedule itself.
Objectives created by a schedule get a generated metadata.externalId shaped like schedule:<scheduleId>:<nanoseconds>, so you cannot set your own external ID on them. Find them by filtering instead:

Overlap: skip or stack

overlapPolicy decides what happens when the previous run is still STATE_PENDING or STATE_RUNNING at fire time.
  • OVERLAP_POLICY_SKIP skips the fire and records why. This is the default, and it is what you want for a digest or a sweep that must not double-post.
  • OVERLAP_POLICY_ALLOW fires anyway, so runs stack.
Leaving overlapPolicy unset stores OVERLAP_POLICY_UNSPECIFIED, which behaves as skip.

Confirm it is running

Read the schedule back with includeInfo and info tells you what has happened.
lastObjectiveId is the fastest way to see what the last run did. lastSkippedAt and lastSkipReason explain a schedule that looks active but produces nothing. info.nextFireAt is the timestamp of the upcoming fire, computed from the spec, so you can confirm a new schedule is live before it has ever run. It is present on an active schedule with future fire times, and absent on a paused or archived one. So a fresh STATE_ACTIVE schedule reads totalFires: 0 with a real nextFireAt, which is exactly the “yes, this runs, at this time” signal a dashboard wants.

Pause, resume, archive

Lifecycle is a set of actions, not a field. state is read-only.
Archiving is one-way. An archived schedule never fires and cannot be resumed, updated, or paused; create a new one instead. Pausing is idempotent, so a retried pause is safe.
A PATCH that sets spec.status returns 200 and does nothing, because no such field exists. Use pause.

Schedule an agent

The hands-on lesson, from cadence to first fire.

Create an objective

What every fire builds, and the fields a schedule carries into it.

Agents and variations

Publishing an agent, which a schedule requires to fire.

Webhooks

Hear about a scheduled run without polling for it.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

workspaceId
string
required

Workspace ID.

Example:

"workspace_01HXKD2E5NQM3T9AYWCF133E3Q"

agentId
string
required

Agent ID. Accepts the canonical agent_… form or the external_id:<value> form.

Example:

"agent_01HXKD2E5NQM3T9AYWCFMGWT9Y"

Body

application/json

Create agent schedule request.

metadata
object
required

CreateResourceMetadata contains the user-provided fields for creating a workspace-scoped resource. Read-only fields (id, account_id, workspace_id, profile_id, created_at) are excluded since they are set by the server.

spec
object
required

AgentScheduleSpec is the user-provided configuration for a schedule.

Response

OK

AgentSchedule resource — a recurring trigger attached to an agent that creates objectives on its cadence.

metadata
object
required

Standard metadata for persistent, named resources (e.g., agents, tools, prompts)

spec
object
required

AgentScheduleSpec is the user-provided configuration for a schedule.

state
enum<string>
required
read-only

The current lifecycle state of the schedule. Output only. Schedules are created STATE_ACTIVE; use the :pause, :resume, and :archive actions to transition between states.

Available options:
STATE_UNSPECIFIED,
STATE_ACTIVE,
STATE_PAUSED,
STATE_ARCHIVED
info
object

AgentScheduleInfo provides read-only runtime data about a schedule.