Put AI work on a schedule

Some work belongs at a future time or on a repeating cadence: every hour, every day, on weekdays, or according to another recurring schedule. Automation makes that timing explicit without requiring a new interactive message each time.

The current workspace only offers a Chatbot for Automation when access_scope === "private" and automation_enabled is true. The Automation also retains its integration and platform context so the scheduled work is routed through the configuration it belongs to.

The schedule answers when. The instruction answers what.

Write an outcome-oriented instruction that will still make sense when it runs later without a fresh conversational prompt. Include the necessary scope and expected result, but keep internal orchestration details out of the instruction.

Choose the once schedule type for work tied to one known future moment. The interface captures that moment and sends it as run_at, while the schedule model also requires a timezone. A one-time schedule is not a recurring cadence.

Choose cron for a repeating cadence. The management UI provides current presets for common schedules and also accepts a custom five-field cron expression; the presets are conveniences, not the only valid expressions.

Both once and cron schedules include a timezone. Keeping it beside the schedule makes the intended local context explicit instead of leaving readers to infer it from a timestamp or expression. The page does not promise timezone behavior beyond the current schedule contract.

The Automations table exposes next_run_at when another execution is expected. It gives you an operational checkpoint for the current definition; when no next run is available, the workspace shows no date rather than inventing one.

The current editor can update the name, instruction, schedule type, cron expression or once datetime, and timezone. Editing changes the managed definition for future behavior; it does not rewrite historical Runs.

Keep the definition while deciding whether it should continue, or remove it when it should not schedule again.

An Automation is the persistent definition: what should happen, when, and through which configured system. A Run is one scheduled execution of that definition. The current workspace reflects this distinction with separate Automations and Runs tabs.

A Run can expose any of the current statuses below. They describe possible lifecycle states; they do not imply that every Run passes through every state in one identical sequence.

The Runs table brings several signals into one view: scheduled time, Automation, Chatbot, platform, run status, delivery status, response time, and error code. Execution and delivery are separate concerns, so one label does not have to hide the other.

Open a Run to inspect its status, delivery, latency, error, and output_message. This is a focused result view—not a promise of full tracing, hidden reasoning, or a step-by-step internal transcript.

Delivery can be pending, delivered, or failed. Keeping delivery status separate from execution status helps distinguish whether the scheduled AI work ran from what happened when its output moved through the configured integration.

The current Runs view can filter by Chatbot, platform, status, and a bounded time range. Available ranges are 1h, 3h, 6h, 12h, 1d, 2d, 7d, 14d, and 30d. This is operational history, not an unrestricted analytics claim.

The Chatbot remains the composition root. Memory attaches to the Chatbot; structured data, documents, MCP tools, and custom behavior are configured through their relevant Agents. Automation schedules work around that existing composition.

The current product supports once and cron schedules. It does not present arbitrary webhook, incoming email, database-change, price-threshold, condition-monitoring, or event-bus events as Automation triggers.

Scheduled tasks work best when their instruction remains meaningful later without a new interactive prompt. That can include a recurring summary, periodic review, scheduled preparation, repeated check, or future follow-up—across any use case where the timing and desired outcome can be stated clearly.