Scheduler (SCHEDULER)

Starts the pipeline automatically at fixed times, for example every morning at 9, with a prompt you write here. No user and no chat are needed.

Category: Flow Control · Deployed: yes · Tool-capable: no

Ports

Port Kind Purpose

Trigger (out_trigger)

Output

Starts the connected modules at each scheduled time

There is no input port — the schedule is the start.

Properties

Field Required Meaning

Cron Expression (cronExpression)

Yes

When to start, as six fields: second minute hour day month weekday. Examples: 0 */5 * * * * = every 5 minutes, 0 0 9 * * MON-FRI = weekdays at 9:00

Prompt (prompt)

Yes

The message the pipeline gets on each start, like a chat message from a user. The first connected module receives it

Session Mode (sessionMode)

No

NEW_EACH_RUN (default): every run starts fresh and remembers nothing. PERSISTENT: every run sees the earlier runs, for example to report only what changed — but this history grows, and runs get slower and cost more over time

How a scheduled run works

  • At each scheduled time, the agent server runs only the modules reachable from this Scheduler. Other parts of the same pipeline — for example a chat path that starts at Chat Input — do not run.

  • A pipeline can contain several Schedulers. Each one runs its own branch on its own schedule.

  • The schedule runs only while the pipeline is assigned to a running agent. A Scheduler that is not connected to anything never runs.

  • A scheduled run has no chat, so the last result is only written to the agent server’s log (and to a DEV report, if you switched one on). Nobody sees the answer. To keep or send the result, end the branch with a module that does it, for example File Write, API Call or KV Store Write.

  • A scheduled run acts as the person who last saved the pipeline. Whoever saves a pipeline with a Scheduler becomes the account its scheduled runs act as, and the editor says so after saving. A run may only use the topics that person may use, and never more than they could at the time of saving. If that person later loses access to a topic, scheduled runs lose it too; if their account is locked, disabled or deleted, the scheduled runs get no access at all until someone else saves the pipeline. Topics the run may not use are skipped through AI Topic, as in a chat.

  • A pipeline saved before this rule existed has no such person yet: save it once to give its scheduled runs access.

The answer of a scheduled run is not kept. Nothing is shown to anyone and nothing is stored by default. If the branch ends without a module that saves or sends the result, the result is lost after the run. Always end a scheduled branch with a module that keeps or delivers the result.

Use cases

  • Nightly report: Scheduler → SQL Database → Agent writes a summary → File Write.

  • Regular check: Scheduler → API Call → Validator → on Fail, an Agent writes a warning that an API Call sends to a chat or ticket system.

  • Recurring digest with PERSISTENT, so the agent remembers what it already reported.

Notes

  • Six fields, not five. The first field is the second. A five-field expression copied from classic crontab examples is not valid here. 0 0 9 * * * means every day at 9:00:00.

  • An invalid Cron Expression stops the whole pipeline. The agent server refuses the pipeline when it is registered, and you see a warning on the agent.

  • Times use the agent server’s clock and time zone. In the agent server’s container this is UTC, unless your administrator changed it. Convert your local time to that zone.

  • PERSISTENT memory is kept only while the agent runs. It starts empty again after the agent is restarted or the pipeline is removed from the agent. Each Scheduler has its own memory.

  • NEW_EACH_RUN is the safer choice. With PERSISTENT, every run also reads all earlier runs, so the cost per run keeps growing.

  • The Prompt is always the same. For changing input, let the pipeline fetch it, for example with API Call or SQL Database.