Schedules & Watchers

Understand time-based and condition-based Starfire AI automation concepts, execution boundaries, and notification behavior.

Schedules & watchers

Schedules and watchers let Starfire automation begin because of time or a monitored condition, rather than only because a person presses Send.

Schedules

A schedule starts work at a defined time or recurrence.

Examples:

• generate a daily project summary
• run a weekly research refresh
• perform a recurring health check
• trigger an organization report

A scheduled workflow should still use the permissions, budgets, models, and tools available to its execution context at the time it runs.

Watchers

A watcher checks for a condition and acts only when the condition is met.

Conceptually:

Check source / state
       ↓
Condition met?
   ┌───┴───┐
   no      yes
   ↓        ↓
stop    start task/workflow

Examples can include watching a project state, integration event, operational signal, or another supported source.

Notification vs action

A watcher can be designed to notify a person, start a workflow, or request approval. Those are different levels of autonomy.

For sensitive workflows, a watcher detecting a condition should not automatically imply that a consequential action is authorized.

Runtime identity

A scheduled or watched run needs a stable owner and execution context so Starfire can determine:

• who owns the run
• which organization policies apply
• which credentials/integrations can be used
• what budget is available
• where results should be delivered

Failure and missed runs

Automation systems need explicit behavior for downtime, missed schedules, expired credentials, and repeated failures. A workflow should not silently create an unlimited backlog after being unavailable.

Status

Schedules and watchers are part of the NEXUS automation direction and can be rolled out independently from basic custom agents.

The presence of this architecture in the docs does not mean every trigger source or cadence is enabled for every account.