Example: a weekly client report
Ask your reporting agent: “Register a weekly report automation for this client. Read its reporting rules, collect the source data, draft the report, request review and save the deliverable. Document the steps and report every run with its task and file links.” The agent needs the source integrations and access to do that work.
Open Automations to review its purpose, runner, visual map, documentation, Context Pack and history. An active automation must have a purpose, documentation and at least one step.
Choose who starts the run
- Run now: pick an eligible runner agent. Emperor creates a task and records a running automation run, with a link to the task. Starting another while one is running requires confirmation.
- The agent runs it from its runtime: the runtime owns the schedule and reports runs to Emperor. This is the default for existing automations.
- Emperor runs it on schedule: opt in per automation. Emperor creates a task at the scheduled time; the agent still executes the steps.
Do not operate both schedulers for the same automation. When you hand scheduling to Emperor, the agent’s own schedule must stop.
Edit the schedule and the work in the app
- Open the automation and select Edit.
- Choose hourly, daily, selected weekdays or custom cron; set a time zone and review the next three runs.
- Adjust purpose, Markdown documentation, ordered steps, step agents, approval gates and the Context Pack.
- Save. The runner receives a message describing the change, and Activity records it.
A schedule saved in the app switches scheduling to Emperor. Fields edited by a person are operator-owned: an agent’s later registration cannot overwrite them. The name stays fixed because agents find automations by name. To return scheduling to the runtime, choose that option explicitly; the stored schedule remains the one the agent should follow.
Ground each run in a Context Pack
Choose the scoped Company Brain sources, pinned notes, tags, retrieval query and character budget that should inform each cycle. Agents resolve the pack before executing and report the source IDs alongside task and artifact IDs. This links the instructions used to the evidence produced.
For the report example, use the client’s reporting procedure and current project brief. Keep the delivered report in Storage rather than treating the Context Pack as output storage.
Understand scheduling and approval limits
Emperor-managed schedules run no more often than every 15 minutes. After downtime, a missed run starts once rather than replaying every missed time. A scheduled time arriving while the previous run is active is recorded as skipped. After three consecutive failures to find an eligible agent, or an unreadable schedule, Emperor pauses the automation and explains why.
A cron day-of-month step such as */2 restarts on the first of each month; it is not a steady every-two-days interval. Review the preview and use chosen weekdays for a predictable weekly rhythm.
Approval gates describe work that must wait for a human. The runtime must honor them and use Emperor’s approval flow. Emperor starts tasks and records results; it does not execute arbitrary workflow steps itself.
Verify results and recover failures
Run history shows its source (a person, agent or schedule), duration, summary and linked tasks. A run Emperor starts closes when its task is done or failed. Inspect failed tasks and their evidence before retrying. Pausing or deleting a registry entry does not remove external runtime code; the runtime must check the automation’s status before running.
Only people allowed to hand work to the runner can edit or run the automation. MCP clients can use list_automations and run_automation. For payloads and deployment configuration, see the complete automation manual.