Automations
An automation stores its instructions, schedules, timezone, runtime group, and repositories to clone. Each run starts a task on the automation’s runtime group, or posts the instructions into an existing task when the automation names one. Its run history links to the resulting conversations, so you can inspect the work or continue it afterward.
Before you create an automation
Creating automations in the dashboard requires the organization admin or owner role.
Automations that start a new task currently require an active organization Slack connection. Open Automations in your project and select Connect on the Slack card if Slack is not connected. An organization administrator can also connect Slack from Organization → Integrations.
To receive a Slack notification, name the destination channel in the automation’s instructions and ensure the bot has access to it. An active organization Slack connection is sufficient for sending notifications. You don’t need to bind the destination channel to the project. See Operator in Slack for connection setup and the separate channel binding used for inbound Operator conversations.
If the work needs source code, register the repository through the project’s GitHub integration. You can select registered repositories to clone when configuring the automation.
Create a daily brief
- Open Automations and select the Daily brief template. The template fills in a name, instructions, and a daily schedule.
- Under Triggers, choose the recurrence and time. Check the displayed timezone, which comes from your browser when you create the automation.
- Under Runtime, keep the Operator or choose another runtime group in the project. See Choose a runtime.
- Read Instructions and adjust the scope. Include the full Slack channel name if you want the result sent to a specific channel.
- Review Cloned repositories. Keep the repositories needed for this work, or leave the selection empty for a report that only reads project evidence.
- Leave the switch Active to enable the schedule, then select Create.
For a custom schedule and prompt, select New automation instead of a template, complete the same fields, and select Save. Templates only prefill the form. After creation, you can edit their instructions and triggers like any other automation.
Choose a runtime
Every automation runs on one runtime group. The dashboard selects the Operator by default. An Operator run uses the Operator agent against the project’s development lane, as an interactive Operator conversation does.
Choose one of your own runtime groups to run your agent instead. Each run uses the group’s default agent on its current production version, so a new deployment reaches the automation without an edit. If the group has no production version, scheduled runs are skipped.
Choose a template
Each template fills in a name, instructions, and a schedule, and asks Operator to post its result to the project’s Slack channel. Filter the templates by Reports, Evals, or Spend, then review the instructions and schedule before you create the automation. Select a registered repository when the work reads or changes Recipe code.
Daily brief
A short morning summary of the previous day’s activity, decisions, and work waiting on someone.
Weekly spend review
Last week’s spend compared with the week before, broken down by runtime, model, and tool, with cost-saving opportunities.
Weekly judge calibration
Checks whether judge results still agree with recent human reviews and reports disagreements that need an expert. It never changes a live judge.
Weekly project knowledge refresh
Records the past week’s durable facts and decisions in project memory, with source links.
Project check-in
Every project includes a Project check-in automation, marked Default. When turned on, Operator checks its open issues, pull requests, and review assignments at 9:00 and 15:00, continues work that was waiting on someone, and reports what still needs attention. It starts Inactive, and it can be edited or turned off but not deleted.
Write instructions for an unattended run
Give a scheduled run enough detail to work without asking you questions. Specify the runtime or project area, the time period to investigate, the action to take, and what should happen when there is nothing useful to report. Include a full Slack channel name when the action includes a notification.
Operator checks existing work before starting another change. Its scheduled workflow limits each run to at most one pull request. When the next step needs a person, it records what is blocked and who needs to respond rather than waiting for an answer inside the scheduled run. State the relevant person’s email in advance for workflows that assign review or follow-up work.
Choose a narrow prompt when you want a narrow action. For example, “report cost outliers” asks for a report; “prepare a tested recipe change and open a draft pull request” also requests repository work. Operator’s project access is the same access described in Operator.
Schedules and conditions
The trigger editor supports daily, weekly, monthly, and hourly schedules. Select Add Trigger to add another schedule to the same automation, such as Monday morning and Friday afternoon. Introspection uses the earliest next occurrence across the schedules and evaluates them in the saved timezone. Check the next run time beside the Active switch after saving changes.
Automations created in the dashboard include a condition that checks whether an earlier task from the same automation is still running. If so, the scheduled run is skipped before any work starts. The same condition applies to manual runs. Separate automations can run at the same time.
The API can store additional conditions, such as requiring new tasks since the previous run or no unfinished issues in the project. Conditions belong to the saved automation. Instructions such as “report only when something changed” are evaluated by the agent while it does the work.
Post into an existing task
Through the API, an automation can name an existing task in task_id instead
of starting a new task for each run. Each run then sends the instructions into
that task’s conversation as the task’s own member:
- If the task is idle, the instructions start a new turn.
- If a turn is in progress, the instructions are added to it as a steering message.
- If the task can’t accept the message yet, a scheduled run retries for about five minutes and is then skipped. A manual run doesn’t wait.
- If the task has been deleted or archived, the run is skipped. It never falls back to creating a new task.
The task’s runtime must belong to the automation’s runtime group. Posting into an existing task does not require the Slack connection.
Schedule a one-off run
A cron automation derives its next run from its schedules. To run something
once at a set time, create a manual automation with a future,
timezone-aware next_trigger_at. After it runs, the slot is cleared and the
automation remains as an ordinary manual automation. To schedule it again,
update next_trigger_at with a new time. Filter the automation list with
scheduled=true or scheduled=false to find automations with or without a
pending run.
Who can manage automations
Organization admins and owners manage every automation in the project. Other
members manage only their own, which they create through the API and which
must post into one of their own tasks. To let your application’s end users
schedule work in their own conversations, add automations:read and
automations:write to the application’s allowed scopes.
Run, pause, and inspect
Open an automation to edit its Settings or view Run history. Save instruction or trigger changes before starting a manual run.
Select Run to execute the active automation now. A manual run uses the saved instructions and conditions, and the next scheduled occurrence is recomputed afterward. The dashboard disables Run while the automation is inactive. A manual run that would start a new task requires the organization Slack connection to remain active.
Turn the switch from Active to Inactive to pause future scheduled runs. Pausing does not stop work already in progress. While runs are active, select Stop all runs to cancel their current work. For an automation that posts into an existing task, this stops that task’s current run.
Run history shows each run’s trigger, repositories, start time, status, and duration. Select a row to open its conversation. A run that did no work appears as Skipped with its reason; check it before treating the skip as a failure.
When Operator finds nothing to do, its scheduled workflow records a quiet run
and answers NO_REPLY. Quiet runs are hidden in history by default. Select the
Show control for quiet runs to inspect them. You can read the result in the
conversation whether or not you requested a Slack message.
Read run events
Runs are also readable through the Events API as
introspection.automation.triggered and introspection.automation.skipped.
See the Data Plane API schema
for automation endpoints, fields, and event payloads.
Related
- Operator explains how the AI engineering agent investigates production evidence, tests Recipe changes, and prepares pull requests.
- Operator in Slack explains Slack connections, channel bindings, and message destinations.
- Runtimes explains runtime groups and production versions.
- Learn from production explains the evidence behind review and improvement work.