The three shapes
Scheduled
Fires on a clock and sends a prompt to the agent, which processes it as a normal turn.
In the Portal, schedules are created with a frequency (Once, Daily, Weekly, Monthly, Yearly), a time, and an optional maximum number of runs. A “Once” schedule becomes an At schedule that deletes itself after firing.
Schedules are built in the creating user’s profile timezone, not the browser’s. There is no timezone picker on that form.
Check-in
A contentless recurring pulse. Rather than sending a prompt, it nudges the agent to look around and decide whether anything needs doing. Its defining property: check-ins are dropped when the agent is busy, not queued. A backlog of pulses never accumulates behind real work. The Portal shows the count of skipped pulses on the automation row. Check-in turns run with a platform-fixed cap of 5 turns, independent of the agent’s own configured maximum. Hitting that cap is a normal outcome, not a failure.Watcher
Fires when a message arriving in the agent’s conversation matches a condition. Evaluation is two layers, and the cheap one runs first. Keywords are mandatory. Every watcher needs at least one, and at least one must appear in the message before the model is consulted. That prefilter is what keeps a watcher from costing a model call per message. The semantic layer then judges whether the condition is genuinely met. Default confidence threshold: 0.7. Message content sent to that evaluation is truncated to 2,000 characters. Watcher evaluation runs after a turn completes and never blocks the agent’s response. A non-match releases the cooldown key, so a near-miss does not burn the window. Scope is binary at the agent’s own tool surface: watch the current conversation (default) or every thread the agent runs in.What fires
Turning it on
Automations are gated in two places, and both must be on. Server level. Scheduled automations and watchers are each enabled per environment. When a family is off, the machinery that would run it is never started.The server-level setting is not visible in the Portal, and it is independent of the agent toggles below. If you are standing up automations for the first time, confirm with your account contact that the family you need is enabled for your environment.
- Scheduled automations — gates At, Every, and Cron
- Event-based (watcher)
- Proactive automations — lets the agent create its own automations during a conversation
Agent-facing tools
With proactive automations enabled, the agent gets these system tools:schedule_*, check_in_every, act_when, and automations_cancel all pass through the admission door as effectful calls. They are not free actions.
Limits
Creation quotas
Daily firing budget
Scheduled and watcher fires draw on the same budget.
Safety
Active hours and expiry
Any automation can be restricted to a window: a start hour, an end hour, and an IANA timezone. Fires outside the window are skipped. An automation can also carry anexpires_at. Past it, the automation stops.
How firing works
Schedules are polled, not driven by a cron daemon. A poller lists automations whose next run has come due, claims each one with a compare-and-swap so only one replica fires it, and enqueues the run. The poll interval is 15 seconds and each cycle takes up to 100 due automations.Two things the product does not do
- Automations cannot be edited. There is no update path — create and delete only. The Portal matches: no edit affordance.
- An automation firing on an unattended surface cannot pause for approval. A tool call that would ask a human is denied instead. Design automations to stay inside what the agent is already permitted to do autonomously.
Next: Workflows — when the multi-step process itself needs to be durable.