Scheduled tasks

The Task Node fires a prompt at a fixed time or interval. It's cron with Claude in charge. Useful for anything recurring — daily report, healthcheck, log inspection, automated deploy.

Add a Task

1. Ctrl K → type task → add Task.

2. Configure in the node form:

   • Schedule kind — Seconds (simple interval) or Cron (full expression).
   • Value — number of seconds or a cron expression (0 9 * * 1 = every Monday 09:00).
   • Prompt — what to send to the agent.
   • Repeat — if checked, reschedule after each fire; otherwise fires once and stops.
   • Delegate to (optional) — name of a neighboring Agent Terminal that receives it directly without you pressing anything.

3. Wire it to the Agent Terminal (port task-fire → input prompt).

Two ways to fire

Typed port: wire the Task's prompt (string-stream) output to the Agent Terminal's prompt input. Each fire delivers the prompt as a new message in the agent.

Agent permission: wire the agent to the Task with the task-set-schedule or task-control connector. Then the agent can schedule tasks instead of you — useful for "agent, schedule a retry 5 minutes from now if this fails".

Schedule examples

Kind	Value	What it does
Seconds	60	Fires every minute
Seconds	3600	Every hour
Cron	0 9 * * 1	Every Monday at 09:00
Cron	*/15 * * * *	Every 15 minutes
Cron	0 0 1 * *	First of the month at midnight
Cron	@daily	Every midnight (alias)

The parser is cron-parser — it accepts aliases (@hourly, @daily, @weekly, @monthly).

How it works under the hood

• The timer is local to the node — not an OS cron. If the app is closed, nothing fires.
• The next fire is visible in the node panel, in exact ms.
• When it fires, it emits the prompt on the output port and, if delegateTo is set, routes straight to that agent's onPort_prompt.

Capabilities exposed to the agent

If the agent is wired to the Task with task-set-schedule or task-full-access, it can:

• setSchedule(kind, value, prompt, autoStart?, delegateTo?, repeat?) — reconfigure.
• start() / stop() — toggle the timer.
• getStatus() — read the current state.

There's a powerful connector: task-delegate-and-fire. Lets the agent schedule a future fire, exit, and when the time arrives, the prompt comes back as a new message. Great for "wait 30 minutes before trying again".

Good habits

• Start with tasks that only read or generate reports — no state mutation.
• Once you trust the behavior, move to tasks that have effects. Even then, review the first few runs.
• Trust the connection permissions. If the agent only has db-read-query, a scheduled task can't drop a table by accident.
• For critical routines, combine: Task → Agent → Process Manager. If the process crashes (ports:crashes->prompt), the agent receives the crash and tries to recover.

Limitations

• No timezone support (always machine-local).
• 5-field cron only (no seconds or year).
• One Task = one prompt. For multiple routines, multiple Tasks.