> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adam.new/llms.txt
> Use this file to discover all available pages before exploring further.

# Scheduled tasks

> Create one-time, recurring, and event-triggered Adam runs and inspect their execution history.

Scheduled tasks let Adam run a saved instruction once, on a recurring cadence, or when a connected application emits a supported event.

## Create a schedule

<Steps>
  <Step title="Open Scheduled">
    Select **Scheduled** in the sidebar, then select **New scheduled task**.
  </Step>

  <Step title="Describe the work">
    Enter the instructions Adam should follow on every run. A name is optional; Adam derives one from the opening of the instructions if you leave it blank.
  </Step>

  <Step title="Choose when it runs">
    Select a one-time date, hourly, daily, weekly, monthly, or custom schedule. The editor shows the next run using your detected time zone.
  </Step>

  <Step title="Create and review">
    Save the automation. Open it later to inspect run history, change its instructions, or adjust its schedule.
  </Step>
</Steps>

## Manage an automation

From **Scheduled**, you can search automations and use the action menu to:

* edit the name, instructions, or schedule;
* pause or resume future runs;
* inspect execution history; or
* delete the automation.

Pausing preserves the automation but prevents future triggers until you resume it.

## Event-triggered work

Adam can create automations triggered by supported events from connected applications. Ask Adam to create the trigger and describe the event precisely.

The Scheduled editor shows an event trigger as read-only because the provider-specific trigger cannot be represented safely as a generic schedule form. You can still edit the automation's name and instructions. Delete and recreate it through Adam to change what fires it.

<Warning>
  Scheduled work can act on connected systems without you watching the run live. Make the target and allowed actions explicit, and require a report-only or approval step when a write would be risky.
</Warning>

## Write reliable instructions

Include:

* the data source or connected application;
* the time window to inspect;
* the expected output and destination;
* what counts as an exception; and
* whether Adam may write changes or must only report them.

<Prompt description="Example weekly review" actions={["copy"]}>
  Every Monday at 09:00 in my local time zone, review the open Arena change orders updated in the previous seven days. Produce a table of owner, status, overdue approvals, and missing attachments. Do not change any Arena record. Save the report as Markdown in the task.
</Prompt>