First make one manual run dependable. Register the automation’s purpose, steps, runner and Context Pack, then choose either runtime-owned scheduling or Emperor-managed scheduling. Keep only one active scheduling owner, review upcoming times and verify each run through its task and evidence.
Prove the weekly report once
Before scheduling a weekly customer report, run it manually with the correct client context, source access and review gate. Save the final file, identify missing inputs and confirm the task can close cleanly. A timer will repeat a broken process as readily as a working one.
Ask the agent to register the recurring work as an automation, with a purpose, documentation and declared steps. The visual map should describe those steps rather than a separate diagram that drifts from the actual contract.
Choose one scheduling owner
When the runtime owns scheduling, it starts each cycle and reports runs to Emperor. With Emperor-managed scheduling, Emperor creates a task for the selected runner at each scheduled time; the runtime still performs the steps.
Choose explicitly per automation. If you move scheduling to Emperor, stop the runtime’s duplicate trigger. Pausing a registry entry does not delete external runtime code, so a runtime-managed cycle must check the automation status before it executes.
Check the time zone and the next runs
In the automation editor, choose hourly, daily, selected weekdays or custom cron, and inspect the next three runs in the intended time zone. Write “Monday morning in the client’s time zone” as an operating requirement before translating it into a schedule.
A day-of-month step such as */2 resets at the start of the month. It is not a constant every-two-days interval. Emperor-managed scheduling has a 15-minute minimum; do not design a seconds-level monitor around it.
Make each cycle resolve fresh context
The Context Pack identifies relevant Company Brain sources, pinned notes, tags, a retrieval query and a character budget. Use it to bring the current reporting procedure into each cycle. Keep changing report data in the source system or linked files, not in a copied instruction that never updates.
Require the run report to cite source IDs and link task and artifact evidence. If data access fails, the cycle should record the gap rather than publish a plausible-looking empty report.
Know which edits belong to the operator
The app editor can change purpose, documentation, ordered steps, step agents, approval gates and context. Fields edited by a person remain operator-owned when the agent later registers its automation again. A schedule saved in the app switches scheduling to Emperor.
The name stays fixed because registration finds an automation by name. Returning scheduling to the runtime is an explicit choice; the saved schedule remains the contract it should follow. Review the runner’s change notification and the next-run preview after editing.
Expect overlap, downtime and missing runners
When a scheduled time arrives during an active run, Emperor records it as skipped. After downtime, a missed run starts once rather than replaying every missed interval. Repeated inability to find an eligible runner can pause the automation; inspect the reason before resuming.
Use Run now to test the full path. Review the history’s source, duration, summary and task link. A run started by Emperor closes when its task finishes or fails. An attractive schedule without those records is not evidence of successful execution.
Turn the next report into an automation
Use the automation guide for editing and scheduling, then connect the results to an agent-maintained dashboard. Keep review before external delivery and verify the runtime has the tools needed to produce the report.