Scheduled AI work needs an execution contract

A schedule says when work should start; it does not, by itself, prove which model, tools, environment, or destination actually handled the run. Scheduled AI work becomes reliable only when the intended execution contract is recorded and the observed run is reconciled against it.

A recent r/OpenAI post described confusion about model and environment behavior across ChatGPT surfaces and a scheduled run. That is one user's report, not a verified product specification. It does expose a general operations problem: configuration at creation time can be mistaken for evidence about execution time.

A scheduled run that was expected to use one model and one environment cannot be accepted from a completion notification alone. Record the intended runtime before scheduling and verify the actual runtime after every consequential run.

Write the contract before the clock starts

An execution contract binds schedule, model, tool environment, input state, destination, completion evidence, and retry policy. The schedule is only one field. The owner also needs to know what version of the task ran, which connected sources it could read, what it was allowed to change, and how success will be observed.

For a consequential task, record at least the task identifier, prompt or workflow revision, timezone, trigger, model requirement, tool requirements, account or workspace boundary, input freshness rule, destination, idempotency key, timeout, retry limit, and acceptance check. Keep credentials out of the record. Name their role and scope instead.

OpenAI's ChatGPT training material describes scheduled tasks as work that can run later or repeat and notes that runs can be reviewed in the Scheduled tab. That supports an important operating habit: review the run. It does not establish that every scheduling surface binds every model, tool, or environment in the same way.

Separate selection from resolution

A creation interface may let a person select a model or open a task from a particular workspace. That selection is intent. At execution time, the scheduler still has to resolve an available model, account context, tools, permissions, and current inputs. If any dependency is unavailable, the system may fail, defer, or use documented fallback behavior.

Production integrations should avoid accidental defaults. The OpenAI models guidance for agents recommends explicit model choice when production behavior depends on it and warns against relying on SDK fallback when the exact model matters. The broader lesson applies to scheduled work: make required dependencies explicit, then observe what resolved.

When the scheduler cannot guarantee a required model, tool, or environment, move the job to an interface that can or narrow the task until the dependency is optional. A reminder that asks a person to perform a tool-dependent step can be safe where an unattended write would not be.

Design for retries and unknown outcomes

A timeout does not prove that nothing happened. A run may write its destination and lose the final acknowledgment. An automatic retry can then create a duplicate post, message, ticket, or payment. Treat a timed-out write as an unknown outcome until the destination is checked.

Use an idempotency key or a stable external identifier when the destination supports one. Before retrying, query the destination for that identifier. If the system cannot reconcile safely, stop and request review. The retry policy should distinguish read failures, preparation failures, reversible writes, and irreversible actions.

Consider a hypothetical daily report that needs Python, a connected drive, and a specific model. The task produces a file, then posts its link to a team channel. The scheduler reports a timeout after file creation but before the message acknowledgment. A blind retry can create a second file and a second post. A contract with a stable report date, destination path, and message key lets the next run discover the first result and finish once.

Keep the dangerous step narrow. Generate a draft before sending, stage a record before activating it, or write to a review queue before publishing. Separate content preparation from external authority so a transient model or tool problem cannot turn into an irreversible duplicate.

Verify the run, not only the notification

A completion notice proves that the scheduler emitted a status. It may not prove that the intended data was current, the required tool succeeded, the destination accepted the write, or the resulting artifact is readable. Acceptance needs independent evidence from the consumer boundary.

Capture a run identifier, start and finish time, resolved model when exposed, tool calls, input versions, destination identifiers, and final checks. For a published article, read the live URL and feed. For a generated file, open it and verify expected sections. For a ticket, fetch the created record. For a message, confirm the destination and content.

Some products expose only part of this evidence. Do not invent the missing fields. Mark them unavailable and decide whether the task remains safe without them. Low-risk reminders may tolerate a small evidence surface. Unattended external writes usually need stronger reconciliation.

Keep product claims bounded

The Reddit report should not be generalized into a claim about every ChatGPT surface or scheduled task. Product behavior can change, and the official pages reviewed here do not define a universal binding between a task, a chosen model, and every execution environment. Test the exact surface and account you plan to use.

For API-owned schedules, pin the model identifier where supported and run task-specific evaluations. The OpenAI API reference notes that prompting behavior can change between snapshots and recommends pinned versions plus evaluations when consistency matters. For product-owned schedules, review the task details and completed run evidence that the product exposes.

The supervised worker guide explains how a host should own timeout, cancellation, and reconciliation. The incident-response evaluation guide keeps the acceptance observer independent from the agent that claims success.

Scheduled AI work is dependable when intent and evidence meet. Record the contract, resolve dependencies explicitly, make writes idempotent, reconcile unknown outcomes, and accept the result from the destination rather than the notification. The clock starts the job. It does not close the proof.