Scheduled Automations

Scheduled automations let the resident Gateway run work later or repeatedly. A job can run an agent prompt, a Skill, a script, or a notification.

Choose a Schedule

Anyy accepts these schedule forms:

Form	Example	Behavior
One-time delay	30m	Run once after the delay
Recurring interval	every 6h	Repeat from the previous run time
Exact time	2026-11-20T09:00:00+08:00	Run once at an RFC 3339 time
Five-field cron	0 9 * * 1-5	Repeat using the configured IANA timezone

Five-field cron schedules require a reliable configured timezone. Dashboard → Cron shows the resolved schedule and next run. Keep the Gateway running. The scheduler polls every minute by default, so due time is not a guarantee of second-accurate execution.

Create from chat

Every weekday at 08:00 in Asia/Shanghai, summarize my open tasks. Deliver the result here.

Anyy can create, list, update, delete, trigger, and inspect the history of automations through enabled automation tools. Ask for the saved job ID, schedule, timezone, and delivery destination, then verify them in Dashboard → Cron. A chat-created job keeps its source session and trusted Channel origin for later delivery.

Create a Prompt Job

anyy cron create \
  --name morning-brief \
  --kind agent \
  --schedule "0 8 * * 1-5" \
  --prompt "Summarize today's open tasks as a concise brief." \
  --delivery-target current_user_default \
  --delivery-channel telegram

Run this after configuring a reliable timezone and a tested default Telegram binding. For Dashboard/TUI delivery, replace the last two flags with --delivery-target gateway. The job saves its resolved Role and Workspace; use --role and --workspace at creation when you need specific identities.

Write self-contained prompts

A scheduled run may not have the conversational context you have now. Include the objective, inputs, allowed tools, and output format in the job prompt. The scheduler delivers the final response through the saved route, so the prompt need not ask the child to call a messaging tool again.

Other Job Kinds

• skill — run a named Skill workflow; supply Skill names with --skills.
• script — run a script under the Profile scripts directory; --script selects this kind when --kind is omitted.
• notify — publish a fixed notification prompt.

Use --toolsets to make the capability boundary explicit and --workdir for the intended script working directory.

Delivery Targets

Target	Meaning
gateway	Publish to the resident Gateway
origin	Return to the trusted Channel origin associated with the run
current_user_default	Resolve the user's default binding, optionally for --delivery-channel
none	Run without user delivery

none is available through Dashboard and CLI; model-facing chat automation tools reserve it for internal scheduler work and reject creating a user automation with that target.

Channel targets resolve to concrete bindings when the job is created. origin requires a trusted Channel origin and cannot be invented in a standalone CLI command. A CLI/Dashboard job without a source conversation does not automatically attach notices to the chat currently open.

Publishing proves dispatch into Anyy’s delivery pipeline, not final receipt by an external service. Changing a Channel’s default binding later does not retarget an existing job; recreate the job for a different destination.

Job execution

Job management updates the existing schedule directly. Agent and Skill jobs create a background session for each execution, using the saved Role, Workspace, and delivery route. Script jobs execute the named script, and notify jobs publish their fixed text without a model call.

Each scheduled occurrence has its own durable run record. pending means accepted for a future scheduler claim; running means execution has started. Completion and result delivery are separate. These occurrences are not the interactive session’s steering or follow-up queue. To test a job, ask Anyy in its creating conversation to run it now, then inspect the finished run and the destination; a queued response alone is not a completed result.

Script runs retain the latest 1 MiB of stdout and stderr separately and show an omission note when older output is dropped. Truncation does not stop the script. Results, history views and delivery retries redact known credentials; if that protection fails, Anyy reports a safe failure instead of returning raw output. Protecting a history view does not rewrite older stored records.

Manage Jobs

anyy cron list --include-disabled
anyy cron update --id JOB_ID --disable
anyy cron update --id JOB_ID --enable --schedule "every 12h"
anyy cron delete --id JOB_ID

List/update/delete look across the selected Profile by default. Use --role and/or --workspace to narrow lookup, or --all-scopes for explicit Profile-wide lookup. Update changes enablement, schedule, or prompt; create a replacement to change name, kind, Role, Workspace, or delivery destination. See Dashboard Cron for run state and visual management.