Overview
The most valuable agent work is often proactive. Withautomations enabled (the default), a deployment runs work on a schedule with no human triggering it — and no cron infrastructure for you to operate.
There are two ways automations get created:
| Created by | How |
|---|---|
| Your customer | Conversationally — “every week, look at our top-performing video and make five variations.” The agent sets up the schedule itself |
| Your product | The Automations API — provision defaults at onboarding, or back an automations dashboard |
Create an automation
Customers just ask the agent in chat. From your product, use the API:schedule accepts a cron expression (UTC) or natural language. See the Automations API for the full field reference.
How scheduled runs behave
Each triggered run is a normal run with the same guarantees as an interactive one:| Guarantee | Behavior |
|---|---|
| Durability | A run that hits a transient failure resumes or retries — it doesn’t silently fail at 3am |
| Isolation | Runs execute inside the customer’s own container, with their memory and files |
| Steering | A run reaching a consequential action pauses and surfaces a steering_request like any other |
| Visibility | Runs appear on the SSE stream and in the automation’s run history |
Manage automations
Customers list, modify, or pause automations by asking the agent — “what’s scheduled?”, “pause the weekly report”, “make it daily instead.” Changes take effect immediately. From your product:Common patterns
- Sleep-time work: prep that finishes before the customer shows up — overnight research, morning briefings, drafts waiting for review.
- Monitoring loops: periodic checks that act or escalate — watching ad performance, flagging anomalies, sweeping for policy issues.
- Content cadences: recurring creative production — weekly variations, monthly recaps, scheduled social posts (gated by steering).

