Automate Work With Chat Automations

An automation is a saved prompt with a schedule. Each time it fires it creates a new conversation and dispatches the prompt into it — it does not append to an existing thread. A week of a daily automation leaves seven conversations, each independently readable, searchable, and forkable.

Typical uses are the prompts you would otherwise retype on a fixed cadence: a backlog sweep, a crash scan, a release-readiness check. Start a Chat Conversation covers doing the same work by hand.

Creating and running automations requires workspace owner or admin permission.

Start From A Template

The Automations area lives inside the Chat module, and it ships with twelve bundled templates — six featured on the front, all twelve in the catalog. The featured six are Daily backlog review, Sentry crash scan, PR triage, Weekly retro prep, Morning brief, and Verification sweep; the rest cover task follow-up, release readiness, knowledge freshness, research watch, weekly planning, and inbox distilling.

A template arrives with a prompt, a schedule, and a mode already filled in, and every one of those fields stays editable.

Or Fill In The Form

Creating one from scratch takes a handful of fields:

• Title — what the automation is called, and the stem of every conversation it produces.
• Prompt — the message that gets sent, written in the same editor as a chat message.
• Schedule — either a cron expression or a single future instant. One or the other, never both.
• Timezone — an IANA zone such as America/New_York. Required, because "nine in the morning" is meaningless without one.
• Working directory — where the spawned conversation runs.
• Provider and, optionally, model — leaving the model empty takes the provider's default.
• Mode — the same postures a chat conversation has, defaulting to Default.
• Notifications — notify on failure is on by default; notify on success is off.

The modal validates the schedule as you type and previews the next five fires, which is the fastest way to confirm a cron expression means what you think. Presets cover daily, weekly, and hourly; anything else is a custom expression.

One caution on cron: missing trailing fields are padded rather than rejected, so a four-field expression is accepted and will fire on a schedule you did not intend. Trust the next-five-fires preview over the absence of an error.

What An Automation Run Can See

An automation fires with every context source switched off. There is no Context Picker selection behind it — no Memory Bank, no Dotabases, no web access, no connectors. This is the one place an automation differs from a conversation you drive yourself.

Write the prompt accordingly. Anything the run needs to know either goes in the prompt text, or comes in through a mention.

Mentions Resolve At Fire Time

You can @-mention a row in an automation's prompt, and the substitution happens when it fires, not when you write it. The row's current title and body are pulled in fresh each run, so an automation that mentions a checklist picks up yesterday's edits without being touched.

If a mentioned row has been deleted or is no longer readable, the mention degrades to a [deleted: …] marker and the run still goes ahead rather than failing. The produced conversation carries a note naming what could not be resolved, so an unresolvable mention is visible in the output rather than silently dropped.

The Two Lanes

Automations come in two types, and the distinction is where they execute.

Chat automations are the default. They run in the server-side daemon, and each fire produces a conversation. Nothing needs to be running on your machine.

Routines run locally, through your operating system's scheduler and a headless runner. A routine created through the API lands in a pending state on purpose and only becomes active once the local registrar has created the scheduled task, so an unregistered routine never looks armed. The daemon skips routines entirely, and running one on demand from the web is refused — a routine's manual run is a local act.

What Happens On A Fire

Each fire runs the following sequence, and several of its steps can end the run early:

1. Permission is checked, and the run acts as the human who configured it.
2. Overlap is refused. If the previous fire is still going, a scheduled tick records skipped (already running) rather than starting a second one.
3. A late fire is skipped, never backfilled. If a fire is missed by more than one scheduling interval — because the daemon was down, say — it records skipped (missed), advances to the next scheduled time, and does not run. A week offline does not produce seven conversations at once. Firing manually is always treated as an explicit "now" and never skips.
4. Mentions resolve, then a fresh conversation is created, titled with the automation's name and the fire time.
5. The turn dispatches, and the outcome is recorded on the automation row along with a link to the conversation it produced.
6. Notification, if the matching flag is on.

Scheduled fires are launched detached, and the scheduler scans about once a minute — so a schedule finer than a minute buys nothing.

Read The Run History

Each automation shows its latest run and a history list built from the conversations it produced. Outcomes are succeeded, failed, cancelled, or one of the skip states — skipped (missed), skipped (already running), and skipped (paused).

Only runs that produced a conversation appear in the history list. A skip produces nothing, so it never appears there — the latest skip shows in the latest-run summary above instead. A failed run does produce a conversation, with the error recorded in it, so a failure can be opened and read.

Automations are rows like everything else, filed in their own Dotabase and sorted by next fire, so the one due soonest is at the top.

Run, Pause, Archive, Delete

Each automation's menu offers run now, edit, pause or resume, archive, and delete. Pausing clears the next run time and stops scheduled fires without discarding anything.

Archive and delete differ in what survives. Archiving keeps the row and its run history. Deleting removes the row and its run-history links — but the conversations it produced survive, because those are rows in their own right. Conversations covers where they live afterwards.

From The Terminal

The CLI carries the same surface. Install the CLI covers getting set up.

dots automations list
dots automations templates

Creating one needs the same fields the form asks for:

dots automations create \
  --title "Daily backlog review" \
  --prompt "Review the open backlog and summarize what changed since yesterday." \
  --schedule "0 9 * * *" \
  --timezone America/New_York \
  --cwd /repos/app \
  --provider claude-code \
  --notify-on-failure

--run-once-at takes an ISO-8601 instant instead of --schedule for a single future run; the two are mutually exclusive. dots automations edit takes any subset of the same fields and adds explicit --clear-schedule, --clear-run-once-at, and --clear-model flags, because clearing a value and leaving it alone have to be distinguishable. dots automations run fires one immediately, pause and resume control scheduling, and dots automations runs prints the history.

dots automations delete is a hard delete and prompts for confirmation unless you pass --yes. Prefer archive when you only want it to stop.

Note that the CLI's own help advertises a narrower set of providers and modes than the platform accepts; the web form offers the full set.