Schedules, reviews, and human control

Run recurring workflows and understand approval, cancellation, retry, and review behavior.

Schedules

Schedules start supported workflows on a recurring rule. Users can create, edit, enable, pause, and delete schedule definitions.

RECURRING WORK

A schedule creates traceable workflow runs

01
Configure
Choose workflow, cadence, timezone, and context.
02
Trigger
Organ starts the next eligible occurrence.
03
Run
The workflow keeps its own immutable input and state.
04
Review
Inspect the resulting run, output, and errors.

Future intent stays separate from completed run history

sequenceDiagram participant Rule as Cadence + timezone participant Schedule as Organ schedule participant Dispatcher participant Workflow participant Feed as Unified work feed Rule->>Schedule: Next occurrence Schedule->>Dispatcher: Start action Dispatcher->>Dispatcher: Resolve tenant, venture, config Dispatcher->>Workflow: Dispatch typed workflow Workflow->>Feed: Persist run and events

A definition stores workflow type, venture, cadence, timezone, task/brief, workflow-specific configuration, and optional department, goal, resource, repository, or model context. Use the workflow types offered in your schedule form; available choices depend on its context. Generic Task also supports recurring schedules, and Department Head has its own orchestration path. Elaboration remains a Discovery follow-on.

Review timezone and recurrence carefully. A paused schedule does not start new runs; it does not cancel work already running.

Schedule cost and history

Schedule cards show occurrence times in your local timezone and an estimated monthly model cost based on measured past runs and the recurrence. No cost history yet means no estimate is available. This is a forecast, not an invoice.

In Settings → Usage & budget, the scheduled-work breakdown shows recorded costs by schedule and lets you open its runs.

Scheduling semantics

The configured timezone determines wall-clock interpretation; do not pre-convert the rule to server time.
Pausing prevents future dispatches but leaves active workflow runs untouched.
Editing a schedule affects future occurrences, not the immutable input already handed to a running workflow.
A missed-run count signals that an occurrence could not dispatch; it does not automatically mean a duplicate should be started.
Schedule deletion removes future intent. Resulting workflow records remain part of operational history.

Review points

Human control is expressed through workflow-specific actions:

approve a discovery candidate;
provide requested input to an escalation;
approve a content draft;
cancel an active run;
retry eligible failed work;
mark externally delivered content as published.

Decisions are recorded so later workflow steps can use them.

Finished work can show a review block with what was delivered, the reviewing executive’s decision, and an expandable full judgement. Use the linked run and delivery evidence to inspect the outcome.

stateDiagram-v2 Running --> Waiting: question or approval Waiting --> Running: answer / approve Waiting --> Running: request changes Running --> Completed Running --> Failed Running --> Canceled

Failure handling

Retry only after correcting the underlying issue, such as an expired credential, unavailable model, invalid repository reference, or missing user input. Repeated blind retries can increase costs without changing the outcome.

If a spending limit or compute limit stops a run, the run fails. Raise the limit or wait for running work to finish, then start the work again.

What to expect

Pending counts and escalation surfaces help locate work, while the final action can live on the workflow page that owns the decision.
Schedule outcomes appear as resulting workflow runs. Use those runs to inspect execution history and errors.