Automation
How to have your scheduler request the same Compute task on a schedule, with each run approved and safe to recover.
Start with one recurring task
Choose one proven task, such as a daily review with a fixed input snapshot and destination. Your customer scheduler decides when an occurrence is due. Compute decides whether that exact request can be quoted and admitted. Keep recurrence state in the scheduler you already operate; keep quote, job, result and usage state in the Compute workflow.
Your agent keeps the goal, task context and final decision. The Kit prepares the permitted input and connects the approved interface; participating Macs process admitted work; Lithi records the occurrence, job, result and evidence. Your agent checks the returned result against the task's acceptance rule before continuing.
The scheduler triggers an occurrence. It does not authorize paid work. Each submitted job needs current Compute access, transfer permission for the exact sealed input, a current quote and explicit execution approval from the person responsible for that work or a bounded approval policy that already covers it.
An agent may identify a suitable task and prepare a supported request within the account, data, budget and timing policy you gave it. It must ask when the request exceeds that scope. Reading documentation does not generate an approval policy, and Lithi does not invent a scheduler to replace the customer scheduler.
Keep time and work separate
A reusable template is configuration. An occurrence is one intended run. A trigger makes an occurrence due. Approval authorizes bounded paid work. A job is work accepted by Compute. None of these records substitutes for another.
Freeze each occurrence
For every due occurrence, freeze the selected input snapshot, stable item IDs, workflow, capability, operation, processing profile, output requirements and approved destination. Keep the prepared instructions, rubric, required evidence and acceptance rule with that brief. Prepare and seal the encrypted artifact through the normal file workflow. Transfer permission for that sealed input is separate from the fresh quote and paid-work approval for those exact bytes.
Keep one occurrence record with its template version, intended instant or authenticated event identity, time zone, deadline, quote, approval, submission key, job or batch ID, result, and delivery outcome. A changed source, destination, policy, or commercial decision is new work.
Treat the approved budget ceiling, permitted data, timing rules and change-approval rule as part of that occurrence's scope. If any of them changes, review the new request and obtain the current approval before submitting it.
Choose timing rules
Use the scheduling intent supported by the quote contract: ASAP, DEADLINE, RESERVED_WINDOW or FLEXIBLE_OFFPEAK. These choices express timing or reservation preference. They do not choose a Mac or guarantee completion. Priority is a quoted preference, not a completion guarantee or permission to spend more.
Your scheduler owns the recurrence details. Set the business time zone, daylight-saving behavior for skipped or repeated local times, overlap policy, allowed lateness, missed-run handling, maximum occurrences, and pause state. Preview resolved instants before enabling requests, including a normal day and clock-change cases.
Do not create a second dispatcher or queue to mirror scheduler state. A disabled schedule creates no new submissions only when pending retries are also stopped in the owning scheduler.
Authenticate event triggers
An event is a notification, not approval to spend or read more data. Authenticate the exact delivery through the sender's agreed profile, resolve the event subject through the approved source account, and check the selected object before preparing input.
Deduplicate by authenticated event identity within its account or subscription scope. A delivery retry must resume the same occurrence and submission intent. Do not fetch arbitrary URLs or treat event text as instructions.
A webhook is a hint about a change, not canonical job state, result evidence, or approval. Keep its verification secret in the handler’s secure configuration, separate from the Compute work key. After authentication, read the current authorized job or result before taking downstream action.
Quote, approve, and submit
Each occurrence still needs current Compute access, transfer permission for the exact sealed input, a valid quote and explicit approval from the responsible person or a bounded approval policy. A timer, event, administrator action or webhook never independently authorizes paid work.
Save the exact request body and idempotency key before submission. Reuse both only for the same unchanged intent. After acceptance, keep the job or batch ID beside the occurrence and read the current state, result, exceptions, usage, and delivery separately.
Before downstream synthesis, reconcile returned coverage, abstentions, uncertainty and schema with the occurrence's brief. A scheduler trigger, receipt or integrity check does not decide whether the returned work answers the task.
Recover without duplicate work
When a submission response is unknown, read the existing request, job or batch before creating anything new. An expired quote needs a fresh quote for work that was not admitted; it does not prove that an earlier submission failed. A changed template or input is deliberate new work with new review.
For a missed run or lost response, use occurrences and replay to find the original occurrence and choose the recovery action. Follow pause and recovery to stop future triggers in the owning scheduler while you investigate. Pausing does not cancel an admitted job, erase a result, revoke a credential, or refund accepted work. Remove only the affected access at its source and read back the result.
If accepted output exists but delivery fails, recover that delivery through delivery recovery. If a job also needs to stop, inspect its state and events in the Compute workflow. For unresolved account, input, quote, or result questions, use Compute Help.
Physical attempts are not automatically customer billing units. The quote and its usage policy define the accepted billing unit. A failed delivery retrieves the same accepted result; it does not create a new occurrence or rerun the Compute work.
Run one approved occurrence
When the template, input, timing, quote, and approval are ready, follow Run work for one approved submission and result read-back. Expand to batches only when the items are independent and share a reviewed intent.