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

# Automations

> Scheduled runs, check-in pulses, and watchers — the three ways an agent acts without a person starting the conversation

An **automation** lets an agent act without a human sending it a message. There are three shapes, and every one of them is off until you turn it on.

## The three shapes

### Scheduled

Fires on a clock and sends a prompt to the agent, which processes it as a normal turn.

| Schedule kind | Behavior                                           |
| ------------- | -------------------------------------------------- |
| **At**        | Fires once at a datetime, then deletes itself      |
| **Every**     | Fires at a fixed interval — minimum **60 seconds** |
| **Cron**      | A cron expression with an IANA timezone            |

In the Portal, schedules are created with a frequency (Once, Daily, Weekly, Monthly, Yearly), a time, and an optional maximum number of runs. A "Once" schedule becomes an *At* schedule that deletes itself after firing.

<Note>
  Schedules are built in the **creating user's** profile timezone, not the browser's. There is no timezone picker on that form.
</Note>

### Check-in

A **contentless** recurring pulse. Rather than sending a prompt, it nudges the agent to look around and decide whether anything needs doing.

Its defining property: check-ins are **dropped when the agent is busy**, not queued. A backlog of pulses never accumulates behind real work. The Portal shows the count of skipped pulses on the automation row.

Check-in turns run with a platform-fixed cap of **5 turns**, independent of the agent's own configured maximum. Hitting that cap is a normal outcome, not a failure.

### Watcher

Fires when a message arriving in the agent's conversation matches a condition. Evaluation is two layers, and the cheap one runs first.

```mermaid theme={"dark"}
graph TD
    M["Incoming message"] --> H["Active hours?"]
    H --> C["Cooldown elapsed?"]
    C --> F["Max fires not reached?"]
    F --> K["Keyword prefilter<br/>case-insensitive, mandatory"]
    K -->|no match| Stop["Stop — no model call"]
    K -->|match| L["Model confirms the condition<br/>against a confidence threshold"]
    L -->|below| Stop
    L -->|at or above| B["Daily budget check"]
    B --> Fire["Fire"]
```

**Keywords are mandatory.** Every watcher needs at least one, and at least one must appear in the message before the model is consulted. That prefilter is what keeps a watcher from costing a model call per message.

The semantic layer then judges whether the condition is genuinely met. Default confidence threshold: **0.7**.

Message content sent to that evaluation is truncated to **2,000 characters**.

Watcher evaluation runs after a turn completes and never blocks the agent's response. A non-match releases the cooldown key, so a near-miss does not burn the window.

Scope is binary at the agent's own tool surface: watch the current conversation (default) or every thread the agent runs in.

## What fires

| Action          | Effect                                           |
| --------------- | ------------------------------------------------ |
| Invoke agent    | Sends a prompt; the agent processes it as a turn |
| Invoke workflow | Starts a workflow run with the given input       |
| Check in        | The contentless pulse described above            |

## Turning it on

Automations are gated in two places, and **both** must be on.

**Server level.** Scheduled automations and watchers are each enabled per environment. When a family is off, the machinery that would run it is never started.

<Note>
  The server-level setting is not visible in the Portal, and it is independent of the agent toggles below. If you are standing up automations for the first time, confirm with your account contact that the family you need is enabled for your environment.
</Note>

**Agent level.** Each agent has independent toggles:

* **Scheduled automations** — gates At, Every, and Cron
* **Event-based (watcher)**
* **Proactive automations** — lets the agent create its own automations during a conversation

All default off. The create buttons in the Portal stay disabled until the matching toggle is on.

## Agent-facing tools

With proactive automations enabled, the agent gets these system tools:

| Tool                                  | Purpose                                    |
| ------------------------------------- | ------------------------------------------ |
| `schedule_at`                         | One-off at a datetime                      |
| `schedule_in`                         | One-off after a delay — maximum **7 days** |
| `schedule_every`                      | Recurring interval                         |
| `schedule_on`                         | Recurring on a cron expression             |
| `check_in_every`                      | Recurring contentless pulse                |
| `act_when`                            | Create a watcher                           |
| `automations_list`, `automations_get` | Read what exists                           |
| `automations_cancel`                  | Remove one                                 |

`schedule_*`, `check_in_every`, `act_when`, and `automations_cancel` all pass through the admission door as effectful calls. They are not free actions.

## Limits

### Creation quotas

| Limit                   | Value   |
| ----------------------- | ------- |
| Automations per agent   | **50**  |
| Automations per account | **500** |

### Daily firing budget

| Limit                     | Value   |
| ------------------------- | ------- |
| Fires per agent per day   | **100** |
| Fires per account per day | **500** |

Scheduled and watcher fires draw on the same budget.

### Safety

| Control                                  | Value             |
| ---------------------------------------- | ----------------- |
| Consecutive failures before auto-disable | **5**             |
| Minimum `Every` interval                 | **60 seconds**    |
| Minimum watcher cooldown                 | **300 seconds**   |
| Default watcher cooldown                 | **3,600 seconds** |
| Default confidence threshold             | **0.7**           |
| Maximum `schedule_in` delay              | **7 days**        |
| Check-in turn cap                        | **5**             |

### Active hours and expiry

Any automation can be restricted to a window: a start hour, an end hour, and an IANA timezone. Fires outside the window are skipped.

An automation can also carry an `expires_at`. Past it, the automation stops.

## How firing works

Schedules are **polled**, not driven by a cron daemon. A poller lists automations whose next run has come due, claims each one with a compare-and-swap so only one replica fires it, and enqueues the run. The poll interval is **15 seconds** and each cycle takes up to 100 due automations.

## Two things the product does not do

* **Automations cannot be edited.** There is no update path — create and delete only. The Portal matches: no edit affordance.
* **An automation firing on an unattended surface cannot pause for approval.** A tool call that would ask a human is denied instead. Design automations to stay inside what the agent is already permitted to do autonomously.

***

Next: [Workflows](/docs/learn/concepts/workflows) — when the multi-step process itself needs to be durable.