Schedules and loops

Noir schedules are persisted work definitions. A runner claims due occurrences and emits normalized messages back into the same agent runtime. This reuses conversation serialization, tools, approvals, output delivery, and observability.

Timing modes

• once: run at one ISO timestamp.
• interval: run every fixed number of milliseconds from an anchor.
• cron: run a cron expression in an explicit IANA timezone.

schedulerCapability({
  store,
  presets: [{
    name: 'daily-brief',
    description: 'Send a product-data brief every morning.',
    timing: {
      kind: 'cron',
      expression: '0 8 * * *',
      timezone: 'Europe/London',
    },
    message: 'Prepare today\'s product-data brief.',
  }],
})

Presets are trusted host configuration. Letting a model choose from presets is safer than letting it invent arbitrary schedules and payloads.

Durability semantics

Each occurrence has a deterministic identity. A store atomically claims it, records the run, and settles success, retry, skip, or failure. Multiple runners can poll the same store without intentionally executing the same occurrence twice.

Misfire policy controls what happens after downtime. Quiet policy controls whether an occurrence is deferred, skipped, or otherwise suppressed during blocked hours. Timezone is part of the schedule rather than an assumption from the server.

Agent-created schedules

The scheduler capability can expose create, list, pause, resume, update, and delete tools. Creation is a write and should use approval or a constrained preset policy. A receipt should include the schedule ID and next run time.

Loops

Long-running agent loops should be modeled as durable schedules or tasks, not setInterval at module scope. A task carries checkpoints and can suspend; a schedule determines when a new occurrence begins. Both survive process restarts when backed by durable stores.

Noir starts no hidden hosted cron. Your process runs the scheduler runner, or your platform invokes its tick method on a cadence.