Automations¶

The Automations page (sidebar > Automations) runs inference tasks on a schedule, with no one at the keyboard: a daily summary of a folder of documents, an hourly status check against a URL, a weekly report draft. Each automation pairs a model (and optionally an agent) with a prompt template, an input source, and an output action.

The page has two tabs: Automations (the list) and Execution History. The Container Tasks tab is hidden in this version until the container task executor is wired; if you have existing container tasks, they appear in a read-only section on the Automations tab so you can inspect their run logs or delete them (see Container Task Scheduling).

Creating an Automation¶

New Automation opens the form below. Create by chat is a preview available in canary builds (the Canary update channel): there, New Automation starts the way you picked last, and the arrow beside it offers both:

• Create by chat (the default in a canary build): a conversation in place of the list asks one thing at a time, offering choices where the answer is one of a few, and you can always type instead. It asks what the automation should do, when it should run (it repeats the schedule in plain words with the time zone and the next three run times), any input it needs, where the results go, which model runs it, and any tools, then shows a summary. Your first message is taken as what the automation should do. Before the conversation starts, the app asks the chosen model about that message: when it seems to need your own account on a service, posting or sending something on another service, or expert judgment that a small model (below 8B parameters) cannot give, a notice says the request may not work and offers Rephrase or Continue. Continue starts the conversation as you asked; a new message takes the first one's place and is checked again. Once the helper has answered, the choices for the next question appear under its message, ending with Type my own, so you can reach the summary by choosing alone. At the tools step the tools the run needs for the result, as the helper judged them from the task, the input, and where the results go, are already selected: click a tool to turn it on or off, then Use selected tools, or pick No tools. Choose from all tools opens every tool, and the tools you turn on there join the others. A task that names a web address while the automation has no input starts with Fetch Web Page selected. A URL input already gives each run the page's text, so summarizing that page needs no tool. When the helper judges that a request needs something an automation cannot do yet (signing in to an external account, posting or deleting on an external service, code saved to run each time, or more reasoning than the chosen model can give), the conversation says so, one line per need, and offers Rephrase or Save as draft anyway instead of the setup choices. The app creates the automation, never the helper: when you pick Create and turn on or Save as draft, it saves the automation to the list and says so in one line, with View in the list. An automation still missing a schedule or a model is saved as a draft even if you picked Create and turn on. A scheduled run has nobody to ask, so when the automation uses a tool that can send, write, or delete something, the summary asks about each such tool before offering its choices: Allow lets a scheduled run use it without asking, and Remove takes it out of the automation. A tool set to ask first is refused on every scheduled run, and the summary says so with the same two choices. Nothing is saved until you decide, and the tools you allowed are listed under the summary. Test run at the summary saves it as a draft and runs it once: the result appears in the conversation and stays in the run history marked Test, and nothing is sent, saved to a file, or posted. You can stop it while it runs, and the conversation goes on afterwards; choosing Create and turn on or Save as draft then updates that same draft. After your first message, a card beside the conversation shows what has been settled so far, marked Not saved until the app has saved it. Open in advanced editor opens the form below with the same values at any point, and Save as draft at the top, shown once something is settled, saves the unfinished automation to the list. The conversation needs a model that can call tools; the model picker lists the others too, marked No tool calling, but they cannot be picked. With a small model (below 8B parameters, counting Gemma 3n E4B as 4B), a notice above the message box says it may not record the answers you type; the choices in the conversation still work. While the chosen model is still loading, a message you send waits and goes out once the model is ready.
• Set up manually: the form below.

A draft is an automation that is not finished: its card carries a Draft badge, it never runs, and Run Now is off. Turning it on, or saving it in the form, finishes it once it has a name, a schedule, a model, and a prompt.

The form has these sections:

1. Basic Info: A name (e.g., "Daily summary", "Hourly check").
2. Schedule: Pick a frequency preset (every 15 or 30 minutes, hourly, daily, weekly) or write a cron expression directly; the expression is validated as you type. The timezone uses IANA names (e.g., Asia/Seoul, America/New_York).
3. Model & Agent: Choose the model that runs the task; the list mixes local model files with the models your registered providers serve. An automation stores a provider model by its model id alone, so a model served by more than one provider appears once in the list and the router picks a provider for each run, moving to another one when the first is unavailable. That is what an unattended run wants, since nobody is at the keyboard to retry a provider that is down. The Agent field defaults to None (direct inference), which sends the prompt straight to the model. With an agent profile selected, the prompt still goes straight to the chosen model, and the profile's system prompt and instructions are placed ahead of the automation's own system prompt. When the automation sets no tool permissions of its own, the profile's apply (see Tools). The profile's preferred model and tool list are not used: the automation runs with its own model and tools. Three toggles control the model lifecycle:
   • Run model automatically before execution: run the model if it is not already running.
   • Stop model after execution: stop the model and free the memory once the run finishes.
   • Catch up missed executions on startup: if the app was closed at the scheduled time, run once at the next launch.
4. Tools: Select which tools the model may call during the scheduled run. With no tools selected, tool calling is disabled for the run. The selection is an allowlist, enforced when the tool is about to run and not only when the tool list is offered to the model: a model that names a tool outside the selection gets a refusal back and continues without it. Per-tool permission overrides in the same section apply too, and fall back to the selected agent profile's permissions when the automation sets none of its own. Because an automation runs unattended, a tool marked Ask once or Ask every time is refused rather than held waiting for an approval nobody is there to give; mark a tool Always allow if the automation needs it.

5. Input Source: Optional external data injected into the prompt as {{input}}:

   • None: no external input.
   • File: the content of a file path.
   • Directory (glob): files matching a glob pattern (e.g., /data/docs/*.txt).
   • URL (HTTP GET): the page at a URL. An HTML page arrives as its main text in Markdown; any other response, such as JSON or plain text, arrives as it is.
   • Shell Command: the output of a command.

   Shell commands

   Shell commands run with the app's permissions and without asking, on every run. Only use commands you trust.

   Shell command inputs are off until you turn on Allow shell commands as automation input in Settings > Tools & extensions > Automation shell commands. While it is off, an automation with a shell command input cannot be saved, imported, or duplicated, and one saved earlier fails its runs with a message naming the setting. An organization policy can lock the setting (tools.allowScheduleCommandInput).

6. Prompt: An optional system prompt plus the prompt template sent to the model.

7. Output Action: What happens to the result:
   • Store in history only: visible in Execution History.
   • Save to file: written into a directory you choose.
   • Desktop notification: shown as an OS notification (the form requests notification permission if not yet granted).
   • Webhook (HTTP POST): posted to a URL.
8. Parameters: Generation settings for the run, including temperature (0 to 2) and max tokens.

Template Variables¶

The prompt template (and system prompt) can include variables that are resolved at run time:

Managing Automations¶

Each automation card shows the model, the schedule in plain words (e.g., "Weekdays at 9:00 AM", with the time zone when it is not yours), the last run result, and the next run time. The form shows the same description and the next three run times under the schedule. From the card you can:

• Toggle between Active and Paused without deleting the automation.
• Run Now to trigger an immediate execution outside the schedule.
• Edit the configuration in the form. In a canary build, Edit offers two ways: Edit by chat opens the same conversation on the automation as it is, with its card and the summary's choices. Say what should change; Save changes saves it and leaves it on or off as it was, Save and turn on is offered while it is off, and Test run saves the changes and runs it once. Edit in advanced editor opens the form.
• Delete the automation. This also removes its execution history; a confirmation dialog asks before proceeding.

Desktop notifications announce when a run starts, completes (with its duration), or fails.

Execution History¶

The Execution History tab lists every run with its automation name, status, start time, duration, and result. Filter by automation, status, or date range, and open a run to inspect its full result or error.

Automating from the API or the CLI¶

Everything on this page is also reachable without the app. The /schedules and /executions endpoints are documented in the Automations API reference, and aigo schedule wraps them from the terminal (see the CLI reference). Both can also export an automation to a file and import it on another machine.

One caution carries over from there: an export document holds webhook URLs and shell command lines in the clear, and an imported automation arrives enabled. Read the API reference's export warning before mailing one of those files around.