Scheduled AI-agent work operates reliably when each due occurrence has a stable identity, a defined time zone and an explicit policy for missed, late, duplicate or cancelled executions. A timer firing does not by itself authorise a tool action, and an agent that finishes an old task may no longer have permission—or a useful reason—to deliver it. The practical design is to separate the recurrence rule, occurrence record, current approval, data window and verified side effect.
This guide explains the machinery for today’s scheduled automation systems, not hypothetical artificial superintelligence. It shows how to handle clock changes, overlapping runs, outages, catch-up policies and unclear external receipts without claiming that retries guarantee exactly-once behaviour. Worked numerical cases distinguish obligations completed on time from slots recovered late or deliberately skipped; every invented quantity is labelled as a teaching example.
Pick the right reading route
If you are new to scheduled systems, begin with occurrence identity and the five time fields. Builders can study catch-up policies, destination-side duplicate protection and the test suite. Parents or teachers can use the reminder exercise; operations readers can begin with the 48-slot recovery ledger and factory transfer case.
Contents
- 1. Schedule a logical obligation, not merely a timer
- 2. Keep the five important times distinct
- 3. Choose wall-clock recurrence or elapsed-duration cadence
- 4. Time zones and daylight saving demand a stated policy
- 5. Separate scheduling eligibility from human permission
- 6. Identify every occurrence without relying on a process ID
- 7. Choose the catch-up policy from the task’s value
- 8. Worked laboratory: 48 slots and six missed runs
- 9. Account for concurrency and limited catch-up capacity
- 10. Constrain the data interval so replay stays truthful
- 11. Watch out for idempotency and unknown external receipts
- 12. Design manual triggers without inventing extra recurrence slots
- 13. Distinguish an execution log from a proof of completion
- 14. Diagnose six scheduling failures
- 15. Build a small state-transition test suite
- 16. Independent practice: an educational reminder system
- 17. Changed-context transfer: scheduled sampling at a factory
- 18. Learning pathway, limitations and responsible deployment
1. Schedule a logical obligation, not merely a timer
A scheduled AI-agent task is an obligation tied to a particular intended occurrence, a scope and a policy for late work. A trigger is only the mechanism that wakes the worker. When a process starts at 09:07 for a 09:00 obligation, the start time does not replace the obligation’s identity or its evidence window. The system still has to decide what 09:00 meant, whether the task is currently authorised, whether that occurrence was already completed, and whether processing a late result would be useful or harmful. This is why a scheduled assistant is more than a timer connected to a model.
Write the task as a record: owner, action, exact recurrence or calendar rule, named time zone, intended occurrence key, data interval, permitted delay, catch-up choice, duplicate-action policy, approval boundaries and stop conditions. Treat those fields as a contract. An agent can choose how to collect and summarise information within its authority, but it should not redefine the calendar rule or permission simply because a retry occurred. The task status must describe real side effects, not just whether a model produced plausible prose.
The first design question is whether an occurrence represents new work or repeated observation. An hourly market summary may need an exact historical interval; a weather-warning check might reasonably use the freshest available forecast and skip obsolete windows; a payment instruction must not execute twice because a scheduler emitted two callbacks. Give these different reader jobs different replay policies rather than announcing that one scheduling setting suits everything.
2. Keep the five important times distinct
A scheduled system may have an intended local time, its resolved UTC instant, a source-data observation time, a worker’s actual start time and a completion time. The distinction matters because these times answer different questions. The local time expresses a person’s expectation, the instant identifies a place in global chronology, the observation time tells us how fresh evidence is, the start time identifies operational delay, and the completion time provides evidence of result delivery. None may be silently substituted for another.
Consider a fictional newsletter-free school digest intended for 08:00 Asia/Singapore, which starts processing at 08:09, reads a record updated at 07:55 and completes at 08:12. The digest should be labelled with the intended 08:00 occurrence while noting that the source was current to 07:55 if that detail matters. Calling it an 08:12 scheduled report hides twelve minutes of slippage. Calling the 07:55 source timestamp the execution time misrepresents what the system did. A reader needs labels with stated meanings, not five indistinguishable dates.
Store instants in a form that preserves offsets or UTC as appropriate and retain the named zone used to interpret future civil-time occurrences. A bare “2026-10-24 08:00” without a zone can be impossible to interpret reliably when workers live in different regions. A named time zone is more informative than assuming one constant UTC offset forever, particularly where daylight-saving rules can change.
3. Choose wall-clock recurrence or elapsed-duration cadence
“Every day at 08:00” is a civil-time rule. “Every 24 hours after the previous execution” is an elapsed-duration rule. They can coincide for long periods and then diverge when a time zone changes clocks or a run starts late. Do not rewrite one into the other without a deliberate product decision. A school reminder anchored to a family’s morning probably wants the wall clock; a polling task designed to wait 24 hours between observations might want elapsed time. Both need clearly defined missed-run behaviour.
An hourly job can also mean two things: a calendar-aligned slot beginning at the top of each hour, or one hour after the last completion. If one execution takes fifteen minutes, completion-based recurrence drifts relative to the wall clock. If it takes seventy minutes, scheduled slots can overlap unless a concurrency policy intervenes. This difference can change the set of source records examined and the number of messages or updates sent. Ask whether the user owns a series of calendar slots or a repetition interval.
A recurrence expression is not a complete operating policy. An iCalendar RRULE describes date occurrences, while a workflow engine decides when to start, how to catch up, whether to overlap, and what failure counts as complete. Treat the recurrence rule as a schedule generator, then add separate execution and permission policies. A model should never infer that generating two occurrences means it has permission to perform a consequential action twice.
4. Time zones and daylight saving demand a stated policy
When a region moves its clock forward, a requested wall time may not occur. When clocks move backward, a wall time may occur twice. These are civil-time ambiguities, not proof that one timestamp is corrupt. For example, under the standard United States daylight-saving calendar in 2026, the America/New_York spring transition on March 8 skips local clock times after 01:59:59 directly to 03:00:00, while the November 1 transition repeats the 01:00 hour. A daily 02:30 New York rule raises a spring gap question, and a 01:30 rule raises an autumn fold question.
The iCalendar specification RFC 5545 and its verified errata warrant careful reading here: a recurrence rule, an explicit DATE-TIME and a real client implementation may not handle nonexistent local times identically. Do not promise that every scheduler skips a missing time, shifts it forward or chooses a particular repeated occurrence. Instead test the exact library and version used, document the interpretation of nonexistent and repeated times, and store the resolved instance key. Where a product promises a particular local-time experience, treat compatibility tests as acceptance tests.
A zone-free UTC hourly poll usually does not face the same civil-time duplication, but it may not meet a human’s “08:00 local” expectation. Conversely, a schedule stated only as fixed UTC may move relative to the family’s breakfast time after a regional clock change. Keep the language honest: choose UTC when absolute periodicity is needed, and named civil zones when the local wall-time promise is central.
5. Separate scheduling eligibility from human permission
Even a perfectly generated occurrence may no longer be authorised. The user may revoke a subscription, change the recipient, leave an organisation or alter which documents may be read. At dispatch time and again before consequential action, check whether the instruction remains active, whether its scope still applies and whether any required approval has expired. A schedule stored last week is not perpetual authority. The fact that a job is “due” describes time, not permission.
Represent a scheduled occurrence through explicit states such as planned, eligible, claimed, executing, awaiting evidence, succeeded, skipped, expired and failed. These are distinct: skipped means policy deliberately did not run the occurrence, whereas failed means attempted work did not meet its acceptance criterion. If an external tool call’s result is unknown, an “awaiting evidence” state is more honest than success or failure by guesswork. A new worker can reconcile a receipt before deciding whether retry is safe.
This is a different focus from the site’s temporal-semantics article. Temporal semantics addresses event times, effective dates and expired authority in the data. Scheduled work addresses the recurrence generator and what a system should do with each intended slot across downtime, human changes and duplicate triggers. Both concepts are needed, but one should not overwrite the other’s scope.
6. Identify every occurrence without relying on a process ID
An occurrence key could combine the schedule ID, its version and the resolved logical slot, for example schedule-42|version-3|2026-10-24T00:00:00Z. The key must remain stable when a worker restarts or a callback is delivered twice. A random worker attempt ID is useful for diagnostics but is not a safe substitute: attempts two and three may concern the same obligation. Attach the occurrence key to saved state, tool requests and reconciliation records where the receiving system supports such a reference.
Do not collapse distinct occurrence versions accidentally. If a recurring publication rule changes from 07:00 to 08:00 while a 07:00 instance is pending, decide whether the old instance is cancelled, honoured or replaced. The version is part of the identity because otherwise a late callback from an obsolete rule might affect the new schedule. A status update should use a conditional comparison against the currently authorised version to prevent a stale worker from resurrecting cancelled work.
The stable key also supports an “already handled” response. If the scheduler emits two delivery events for the same slot, a resource-side uniqueness constraint or idempotency record can reject duplicate final effects. This should be enforced where the irreversible operation happens, not merely in a model’s instruction to avoid duplicates. Model reasoning is not a database uniqueness guarantee.
7. Choose the catch-up policy from the task’s value
Missed scheduled slots are not interchangeable. Replay-all is useful for historical extraction where every fixed data interval must be processed exactly in scope. Replay-latest may suit a status check whose older values are obsolete. Skip-expired is appropriate when the user’s benefit disappears after a deadline. Hold-for-approval can be appropriate for costly, financial or sensitive actions whose context may have changed while the system was offline. Some tasks need a combination: record each missed slot, replay only those still within a fresh evidence window and mark the rest explicitly skipped.
Specify the permitted lateness in measurable terms. “Catch up soon” does not tell a worker whether a six-hour-old news digest should be sent. A policy could say a school lunch reminder is useful only before lunch, while a monthly audit must be completed regardless of delay subject to access checks. Different domains require different deadlines. If an action could surprise a user, its late execution may be worse than an explicit skipped status, even when replay would improve a completion graph.
Never equate replay with reenacting the world as it was. A late run may query today’s updated database, not the historical snapshot. If the task requires a historical answer, pin the data interval and acquire appropriately versioned sources. If those sources do not exist, report the limitation and avoid inventing an accurate-sounding reconstruction. The schedule key identifies the obligation; it does not create missing historical evidence.
8. Worked laboratory: 48 slots and six missed runs
Consider a fictional hourly monitoring schedule covering exactly 48 expected slots, two days with 24 UTC hour slots each. Forty-two slots are delivered on time. A temporary outage prevents six planned slots from dispatching. A recovery policy requires review of each missed occurrence; two are still useful and can be replayed, while four have passed their freshness deadlines and must be labelled skipped. Thus all 48 slots are accounted for as 42 on-time completions, two late completions and four deliberate expirations. The numbers reconcile: 42 + 2 + 4 = 48.
On-time completion rate is 42 / 48 = 87.5%. Eventually completed fraction is (42 + 2) / 48 = 44 / 48 = 91.67%. Initial missed-slot fraction is 6 / 48 = 12.5%. Recovery among missed slots is 2 / 6 = 33.33%. Deliberate skip fraction across all planned slots is 4 / 48 = 8.33%. These statements have distinct denominators and should not be substituted for one another. A team reporting “100% accounted for” may be technically correct about bookkeeping but misleading about service delivery.
Now suppose one of the two replayed occurrences receives a duplicate callback. The physical callback count rises by one, but the accepted logical-slot count must remain 44. If the external notification system cannot deduplicate by the occurrence key, the workflow needs a destination-side ledger and receipt reconciliation before another send. A duplicate callback is not a new obligation and must not improve the completion numerator. This distinction is important for billing, notifications and publication.
9. Account for concurrency and limited catch-up capacity
Backfill can consume the very capacity needed for current work. Suppose a system has six runnable slots immediately after an outage—five historical catch-ups and one current slot—but a constrained worker pool can complete only three in the next hour. Even if all six are authorised, claiming them all as complete is false. One policy reserves one capacity unit for current work and uses two for backfill; another prioritises the oldest valid historical slot. Each choice has different fairness and freshness consequences, so make it explicit.
Do not let unlimited overlap create an avalanche. A scheduled run that takes seventy minutes with an hourly trigger will usually overlap another run if concurrency is unrestricted. Limiting active runs can protect shared resources, but may produce a growing backlog unless old slots expire or capacity increases. Distinguish queue admission from successful execution and explain whether a skipped slot counts toward the user’s service promise.
Queue age, run duration, deadline expiry and resource demand are operational measures, not just model tokens. Track scheduled-to-claimed delay, claimed-to-start delay, duration, time spent awaiting human review and end-to-end completion. A dashboard that reports only average worker runtime can hide a three-hour pre-start queue. If an agent is intended to act on current conditions, age at the moment of evidence collection may matter more than the model’s generation time.
10. Constrain the data interval so replay stays truthful
An hourly report often refers to a closed interval such as 09:00 inclusive to 10:00 exclusive. Treating both endpoints as inclusive can double-count events at 10:00 in adjacent windows. Define the interval convention once and require the query to respect it. The date used as a scheduler’s logical label should not automatically be interpreted as the moment the work actually executed. Apache Airflow’s documented distinction between logical dates, run instants and data intervals is a useful engineering reminder.
Suppose a fictional shop log records three entries at 09:00, 09:40 and exactly 10:00. The interval [09:00, 10:00) contains the first two entries and excludes the third. The next interval [10:00, 11:00) contains the third. The sum across adjacent intervals is three, not four. If a replay query instead asks for “the last hour” relative to its delayed start at 11:20, it would cover 10:20 to 11:20 and no longer answer the original 09:00 obligation. An occurrence must carry the data window it is supposed to process.
Not every scheduled task operates on fixed event intervals. A periodic health check samples current state and cannot be “replayed” later as if the earlier condition were known. A weekly educational reading prompt is a human-facing activity, not a data interval. State the semantics of the task and choose its source query accordingly. The system is more reliable when it declines an impossible historical claim instead of producing a confident approximation.
11. Watch out for idempotency and unknown external receipts
An AI worker may send an approved message, lose its network connection before receiving confirmation and then face a timeout. The timeout alone cannot establish that the message failed. Re-sending may produce a duplicate. Preserve the occurrence key and the external request identity, inspect the provider’s receipt or destination record if supported, and only retry when the result is reconciled or the destination guarantees deduplication for that key. The no-duplicate promise must be enforced by the responsible boundary.
When a tool does not support idempotency keys, the workflow may need a stronger protocol: stage a pending intent, check whether the target object already exists using an authoritative exact ID, obtain a human decision for uncertain irreversible effects, or choose not to retry automatically. A publish operation is a vivid example: if the response is lost, read back the exact intended slug and post ID rather than creating a second nearly identical article with a -2 suffix. The worker should never use a superficially different title to bypass the unresolved state.
One job can have several internal attempts without representing several user-approved tasks. Track logical occurrence, attempt number, external operation ID and receipt separately. That model also helps diagnose why a service generated repeated model calls: they may be retries for one slot, not extra authorised analysis.
12. Design manual triggers without inventing extra recurrence slots
A person may press “run now” while a regular occurrence is pending. Decide whether the manual run is a distinct one-off action, a retry of an existing slot or a replacement for the next planned slot. Each interpretation needs a different key and permission check. An operator’s intent should be stored with the manual trigger, not guessed from the fact that a button was clicked. If the run would duplicate an external action, show that risk before proceeding.
Pausing a schedule should suppress new dispatch, but teams must also decide what happens to work already running. Does pause allow a claimed job to finish, request cooperative cancellation, or require all downstream actions to stop? Removing a schedule entirely needs retention rules for history and receipts. A cancellation that happens after the external effect cannot retroactively prevent it; the system should record the outcome and plan authorised remediation rather than reporting a clean cancellation.
Resumption is a controlled transition. Re-read the latest schedule version, user permissions and missed-slot policy before creating catch-up work. Do not allow an old listener to wake after the schedule was paused and post a historical message simply because its original timer finally fired. A safe scheduler makes its current source of authority explicit at every transition.
13. Distinguish an execution log from a proof of completion
A log line saying “job started” proves only that a particular process announced a start. A successful model response proves only that content was generated. The acceptance criterion may require a saved record, a verified audience, a file check, a human sign-off or a real delivery receipt. Define the completion evidence before designing the schedule. Otherwise a system can accumulate green checkmarks while users receive nothing useful.
For an informational recurring task, completion may mean a report exists under the correct occurrence key, contains supported sources from the requested interval and is visible at the intended destination. For a conditional watch, no alert when no condition was met may be a correct result; log the evaluated conditions so silence is explainable. For a scheduled edit, a verified readback of the changed original record may be necessary. These distinctions help the user interpret an empty hour without confusing it with a failed automation.
Separate user notification from internal evaluation. A watch can run, find no relevant change and properly create no notification. That is not a failed run. Conversely, if an alert condition is met but delivery fails, the watch evaluated correctly while the user-facing obligation remains incomplete. A reliable state model retains those two results separately.
14. Diagnose six scheduling failures
Failure one: a daily local reminder drifts by an hour after daylight saving because the application stored only a fixed offset. Repair: retain the named zone and test transitions. Failure two: enabling an old schedule suddenly executes months of stale notifications. Repair: specify a backfill policy and deadline before re-enabling. Failure three: a retry publishes a second article with a suffixed slug. Repair: reconcile the original logical occurrence and intended destination object before create. Failure four: a job uses the worker’s start time instead of its assigned historical data interval. Repair: make interval bounds immutable occurrence inputs.
Failure five: two workers claim one slot and both issue an external action. Repair: use a resource-side uniqueness or conditional claim mechanism, plus destination-side deduplication. Failure six: the team marks a watch failed whenever it does not notify users. Repair: distinguish condition evaluated/no event from a real evaluation or delivery failure. These are not random bugs: each reflects an implicit assumption about identity, time, authority or acceptance evidence.
The investigation should preserve the exact schedule version, intended slot, stored timezone, resolved instant, claim attempts, source observation times, destination receipts and final disposition. A neat text explanation is useful but cannot replace the missing record of what actually happened. For hard-to-reproduce clock bugs, synthetic calendar tests are safer and cheaper than waiting for the next real transition.
15. Build a small state-transition test suite
Test an ordinary on-time occurrence first. Then inject a worker restart after a claim but before any external action; another after the external action but before its response; two duplicate callbacks for the same slot; a late arrival after the freshness deadline; and cancellation during execution. For each case, write the expected disposition and the exact evidence needed. The goal is not only “no exception thrown”; it is no duplicate consequential effect, accurate slot accounting and honest user-facing state.
Exercise recurrence generation with a named time zone across both forward and backward clock transitions, month ends, leap days and any exclusion dates that matter. Confirm how the chosen scheduler treats invalid local times and ambiguous folds rather than assuming conformance from a similar library’s behaviour. If the schedule expression supports DTSTART, RRULE, RDATE and EXDATE, test their interactions on small enumerated calendars. Preserve expected occurrence IDs as fixtures so a library upgrade cannot quietly change them.
Test control changes as well: edit the schedule while an old occurrence is queued, revoke access after an occurrence is due, pause before a callback arrives, resume after multiple missed slots, and manually retrigger a previously completed slot. A passing suite proves only the scenarios represented; it does not guarantee all real-world failure modes. But it forces the team to turn a vague scheduling promise into reviewable invariants.
16. Independent practice: an educational reminder system
Imagine a revision assistant is asked to deliver a short study prompt every weekday at 18:00 in a named home time zone. A learner pauses it for two days and re-enables it after the weekend. Write the policy for those missed days. A reasonable design is to resume on the next eligible weekday rather than replay several obsolete prompts at once, but the right answer depends on the learner’s explicit intent. Preserve the skipped occurrences with reasons, and ensure an already-open study task is not replaced without consent.
Now suppose a prompt is prepared at 17:59, the device loses connectivity, and the send endpoint acknowledges nothing. On reconnection at 18:10, the assistant must not assume that silence means delivery failed. It should inspect a stable message or occurrence ID at the destination if supported. If the endpoint cannot be reconciled safely, ask for user or operator resolution rather than risking duplicate notifications. The quality of the educational content does not settle the delivery question.
Finally, the learner changes zones while travelling and says “keep it at six in the evening wherever I am”. This is a different schedule contract from “six in my home zone”. Update the named location or explicit zone according to that request, version the rule, define the transition between previous and next occurrences and do not silently alter already-delivered slots. Precise language about time is part of respecting the learner’s autonomy.
17. Changed-context transfer: scheduled sampling at a factory
Transfer the mechanism to a hypothetical factory sensor review. A worker records the 08:00–09:00 interval but only becomes available at 11:30 because connectivity failed. The required report must summarise exactly that interval using retained sensor readings. If the retained measurements cover only 08:20–09:00, the assistant cannot honestly fill the missing first twenty minutes. The correct response is an incomplete interval report with a 20-minute coverage gap, not a synthetic average labelled as full-hour observation.
Suppose readings are taken every five minutes starting at 08:00, so a complete half-open hour expects twelve readings at 08:00 through 08:55. If records start only at 08:20 and continue every five minutes to 08:55, there are eight observed readings; four of twelve expected readings are missing. Coverage is 8 / 12 = 66.67%, and missingness is 4 / 12 = 33.33%. The 09:00 reading belongs to the next interval by the chosen convention. A recovered run can legitimately produce this coverage diagnosis, but cannot claim the historical sensor data was complete.
Now change the output from a factual interval report to a real-time safety alarm. Replaying a stale 08:00 alarm at 11:30 may confuse an operator or distract from current hazard conditions. The action policy must distinguish historical audit from current response. The same scheduler infrastructure supports both applications only when each occurrence carries an explicit relevance window and the result describes what it actually means.
18. Learning pathway, limitations and responsible deployment
Schedulers operate amid imperfect clocks, network delay, stale permissions and unavailable data. No finite set of retries guarantees exactly-once real-world side effects across arbitrary external services. Reliability therefore comes from stable identities, resource-side guards, bounded recovery, explicit state transitions and honest reconciliation. An agent may plan a task or generate content, but time correctness and final action authority must be enforced by surrounding software and people. This remains true regardless of future model capability.
Students can learn this topic by drawing an hourly number line and marking expected, missed, replayed and skipped slots. A developer can then write tests for clock transitions, occurrence keys and data intervals. An operations professional can define service-level targets for lateness and duplicate suppression. A teacher or parent can learn why a useful scheduled prompt is one that arrives at the right time, not simply one that arrives eventually. These are transferable skills in systems thinking and numerical honesty.
The intended goal is not to maximise the count of green runs. It is to fulfil the user’s actual time-bound instruction while controlling surprise, preserving privacy and distinguishing historical facts from current observations. When an occurrence no longer has legitimate value, recording “skipped under policy” may be better evidence of a functioning system than an unnecessary late action.
Frequently asked questions
Should a missed hourly run always be replayed?
No. Replay if the task’s defined value and evidence interval survive delay; otherwise skip, use the latest observation or seek approval. The policy must be chosen for the particular task.
Is “every 24 hours” the same as “daily at 08:00”?
Not always. A wall-clock recurrence in a zone with daylight-saving changes and an elapsed 24-hour cadence can differ. Store the promise you actually made.
What happens when an execution gets no tool response?
An absent response is not proof of failed side effects. Reconcile by stable occurrence or destination ID before retrying; preserve an uncertain state if verification is impossible.
Can a job succeed without sending a notification?
Yes. A conditional check that finds nothing requiring an alert may succeed without notifying. Record the evaluation and distinguish it from failed delivery.
What does catch-up percentage measure?
Specify whether the denominator is all planned slots or only initially missed slots. Recovered-late counts and intentionally skipped counts need separate reporting.
What about daylight saving and RRULE?
Test the exact calendar library and zone. RFC 5545 has verified errata about nonexistent local times, so one blanket claim about all implementations is unsafe.
Primary sources and standards
The iCalendar specification RFC 5545 defines recurrence and date-time concepts; inspect its verified erratum 4271 before asserting how nonexistent local times work. Apache Airflow’s timetable documentation distinguishes trigger and data-interval schedules, their logical dates and catch-up policies. The Airflow DAG-run documentation illustrates scheduled intervals, reruns and manual triggers. These sources establish mechanisms; they do not describe the fictional systems or counts in this guide.
Continue your learning
Explore the Super Intelligence hub and How X Works hub. For related but different specialist problems, see agent temporal semantics for effective dates and expired authority, agent disaster recovery for restoration objectives, and backpressure for congestion. Learn why technical knowledge should transfer to daily decisions through the Gold Standard of Education.