Schedules And Reminders
Give an agent an explicit time and outcome when you want it to act later. A standing charter explains its job; it is not, by itself, confirmation that a schedule exists.
Create scheduled work
For a recurring task, include the cadence, time zone, work to perform, and delivery destination:
Every weekday at 9:00 AM America/New_York, check the renewal tracker and post upcoming renewals here in chat. Name the schedule "Weekday renewal check." Confirm the next run time before we rely on it.
For a one-time reminder, use an exact date and zone:
On October 15, 2026 at 2:00 PM America/Los_Angeles, remind me here to review the supplier renewal. Create a one-time reminder named "Supplier renewal review" and confirm its scheduled time.
Specify whether a scheduled result should stay in chat or be sent outside the platform. Email still follows contact permissions and Review Before Send; a scheduled send can wait for approval.
Verify the schedule
Ask the agent to list the schedule's name, enabled state, next run, and time zone. Inspect the schedule update in the timeline. If the time is ambiguous, clarify it before accepting the result.
Named schedules support recurring work and one-time reminders. An agent may also have a primary schedule configured through its settings or API. When investigating unexpected runs, ask it to inspect both its primary schedule and named schedules.
Use an IANA zone such as America/New_York for local calendar time. A fixed UTC time and a local morning time behave differently across daylight-saving changes. Named schedules default to UTC if no zone is supplied, so state the zone explicitly. Avoid ambiguous clock times around daylight-saving transitions when the exact occurrence matters.
Change or stop a schedule
Use its name to avoid adding a duplicate:
Change "Weekday renewal check" to 10:00 AM in the same time zone. Update the existing schedule and tell me its next run.
Disable "Weekday renewal check." Keep the agent available for messages and leave its other schedules unchanged.
Ask to remove a schedule when it is no longer needed. Disable it when you expect to use it again. To suspend all normal agent processing, pause the agent as well.
Limits and missed work
Schedules are subject to deployment limits on total schedules, enabled schedules, and recurring frequency. An inactive agent, license or security restriction, unavailable integration, or missing worker can prevent useful work even when a schedule exists.
If a run appears missing, check the next-run time and zone, activity state, usage, and timeline. On a customer-run deployment, the scheduler and appropriate workers must be running. Do not assume every missed occurrence will be replayed after downtime. Inspect what actually completed, then request any necessary catch-up explicitly.
For updates driven by another service, inbound webhooks can avoid repeated polling. They still require a configured sender and instructions for handling the event.
Deterministic client configuration
Authorized API clients can use named-schedule REST CRUD with explicit expressions, timezone, stable IDs and conditional revisions. Disabling/deleting affects future desired occurrences, not already admitted work. Ownership moves and emergency reset fence named revisions, skip overdue recurring targets and disable overdue one-time timers; future timers retain their target. Scheduler publication/repair is distinct from successful agent execution.