Skip to main content
POST
Add a scheduled brief
A scheduled run only proposes. It reads and asks your knowledge at once, and anything it would change in another system waits for a person, whatever your approval policy allows. It first runs at the next time it names. At most 20 schedules, and a limit on runs per organisation per UTC day. Each run acts as you, authorised afresh, so it stops if you lose the role. Requires owner or admin, signed in: an API key is refused with 403. Every change is audited.
AI employees are in beta. Every route answers 404 unless your deployment has switched the beta on, and these routes need a second switch, off by default. See Schedules and the daily summary.

Path

string
required
The employee: support, itsm, devops, marketer, sales or finance.

Body

string
required
What the brief is about.
string
required
daily or weekly.
integer
required
The UTC hour, from 0 to 23.
integer
0 for Monday to 6 for Sunday. Required when weekly; ignored when daily.
string
The brief. Cut, not refused, past 8000 characters.
string
Who the work is for, where the employee needs one.
string
What it is about elsewhere: a ticket key, a record id.
string
DevOps: the service it is about. Required for devops.
string
The assistant whose knowledge answers questions in this work.

Response

201 with the schedule.
string
required
The schedule.
string
required
The employee: support, itsm, devops, marketer, sales or finance.
string
required
What the brief is about.
string
required
daily or weekly.
integer
required
The UTC hour, from 0 to 23.
integer | null
required
0 for Monday to 6 for Sunday. null when daily.
boolean
required
Whether it is paused.
object | null
required
Its latest run in the last eight days: status (running, done, failed or skipped), started_at, task_id and reason.
Also body, requester, reference, service, assistant_id, created_by and created_at.
Last modified on November 3, 2026