Docs · Schedules
An always-on agent is mostly a list of scheduled tasks. Each task is a cron schedule plus a standalone instruction; the agent wakes up, does the work, and goes back to waiting. This page covers schedules, what else can trigger an agent, and where to review what happened.
A task has three parts: a kebab-case name, a 5-field cron schedule evaluated in UTC, and a prompt. Write the prompt as a complete, standalone instruction, the agent receives it fresh on every run, with no memory of your intent beyond what the prompt and its workspace contain.
5-field cron, UTC
0 9 * * 1-5 every weekday at 09:00 UTC */30 * * * * every 30 minutes 0 6 1 * * the 1st of each month at 06:00 UTC
Templates ship with default tasks. You can edit them at deploy time (full setup → Schedule step), tune cron times per client, adjust prompts, without cloning the template, and edit them again later on the deployed agent.
When several agents share an environment, tasks can declare how much room they need.
Schedules are one input. Agents also respond to messages, and every session is tagged with its source so you can tell them apart in usage views.
Operations that change infrastructure, provisioning an environment, deploying an agent, run as jobs with live progress. Each job keeps a record you can revisit under Jobs, so a failed step is diagnosable rather than a mystery.
The agent page is the operations surface for a single agent.
UTC. Cron expressions are 5-field and evaluated in UTC, convert your local intent accordingly.
The fastest way to understand the flow is to deploy a template and watch its first run.
Start free trial