Features

Automations

Put the agent on a schedule: a nightly code review, a CI poller every 15 minutes, a weekly report. Automations are local-first scheduled runs with sane failure behavior and the same safety gates as everything else.

Creating one

Open the Automations view and press Create automation. The dialog asks for:

Name, and the projects it applies to
Prompt: what the agent should do each time; skill chips render inline, so "/page-report the status page" works
Schedule: Daily or Interval in the dialog, with cron expressions available for precise control

The view lists automations as rows: name, schedule chip, last run, and an enabled toggle. Each fire creates an ordinary run with a full event log, visible in history like any other.

Trigger types

Trigger	Fires	Example
`cron`	On a cron expression	`0 2 * * 1-5`: weeknights at 2am
`interval`	Every fixed period	every `15m`
`one_shot`	Once, at a set time	"run this Sunday night"
`manual`	Only when you press run	a saved job you trigger yourself
`heartbeat`	Progress checks without model calls	stale-agent detection
`event`	On a matching event	react to a recorded event

Worked examples

nightly code review

name: nightly-review
trigger: cron "0 2 * * 1-5"
prompt: Review recent changes, summarize risks, and list follow-up checks.
missed_fire_policy: fire_once

CI poller

name: ci-poller
trigger: interval "15m"
prompt: Check the current CI status for this branch and summarize failures only.
limits: max_duration_seconds 3600, missed_fire_policy skip

weekly report

name: weekly-finance-report
trigger: cron "0 8 * * 1"
prompt: Build a local finance summary from approved finance-read tools and save a report artifact.

A maintenance loop can read its prompt from a project file (anymo/loop.md, falling back to loop.md), so the instructions live in your repo.

What happens when your machine was off

Automations fire only while a host is running. When a schedule was missed, the missed-fire policy decides: skip ignores missed slots entirely, fire_once runs a single catch-up. There is deliberately no replay-everything option, so a laptop closed for a week never reopens to a storm of stale runs. Cron lookahead is horizon-capped for the same reason.

Goal loops: scheduled until done

An automation can carry a goal condition: after each scheduled run, the evaluator checks it. Achieved means the automation completes itself; not achieved means the next fire includes the evaluator's feedback. Stop clauses bound the loop: max turns, max duration, and max cost. Automations that fail repeatedly auto-archive instead of grinding forever.

Hosting: desktop or a Linux server

Two hosts can run the scheduler:

The desktop app, while it is open.
An app-server with --remote-runner, which runs natively on a Linux box and keeps schedules firing around the clock:

on a Linux server

anymo app-server --workspace /srv/anymo --unix-socket /run/anymo/app-server.sock \
  --token "$TOKEN" --remote-runner

Manage remotely over the same API: automation/list, create, pause, resume, delete. See App-server API.

Permissions for unattended work

Scheduled runs use a deliberately narrower permission posture than interactive ones, and the usual gates hold: shell, browser, destructive, and other sensitive actions still require approval, which an unattended run cannot grant itself. Risky steps queue as approvals for you; safe work completes on schedule. Every scheduler decision is recorded as an automation event for audit.

Frequently asked questions

My automation never fires.

Check that a host is running (the desktop app or an app-server), that the automation is enabled and not paused, and remember missed slots are skipped by design; the next due time fires normally.

Where does the output go?

Each fire is a normal run: artifacts land in the workspace, the event log records everything, and the run appears in history. Memory and skill proposals from scheduled runs wait for your review like any other.