“Run every morning” sounds like a complete instruction until the first real-world exception.
What happens if the system starts late? What if the previous run is still working? What if the inputs are now stale? What if a review boundary is waiting for a person? What if a run starts twice, or cannot prove whether its prior attempt finished?
For a simple, idempotent background task, a scheduler may be enough. For an agent that researches, edits, evaluates, or prepares consequential work, the schedule is only the trigger. The workflow still needs a policy for whether a particular run is eligible to begin, what it owns, which information it may rely on, and how it leaves an auditable result.
A schedule tells a system when to wake up. A run contract tells it when, why, and under which conditions it may proceed.
Kubernetes' CronJob documentation is a useful operations reminder even outside Kubernetes: recurring jobs have time zones, missed-run behavior, overlap policy, suspension, history, and idempotency concerns. Agent systems inherit these concerns and add more: source freshness, user authority, task continuation, and human-readable progress.
First-party guidance on long-running agent work points in the same direction. Anthropic's harness account describes structured task artifacts across sessions, and OpenAI's model guidance emphasizes preserving important state and constraints. Those sources do not prescribe recurring-run policy; they support the narrower need for durable state when a run outlives one model turn.
A trigger is not a run
It helps to distinguish three related concepts:
- Concept: Schedule — Question it answers: When should work become eligible? — What it does not answer: Whether a particular instance should actually start
- Concept: Run — Question it answers: What happened during one attempt to do the work? — What it does not answer: Whether its output is still current or authorized to advance
- Concept: Outcome — Question it answers: What durable result, hold, or record did the run leave behind? — What it does not answer: Whether the next scheduled moment should reuse, replace, or ignore it
Conflating these terms creates common failures. A system sees a scheduled instant and assumes it must create work, even though a current run already owns the task. Or it sees an old successful run and treats its output as fresh, even though the relevant inputs have changed.
The right unit of control is the run: a named, bounded attempt with a beginning condition, a current state, and a final disposition.
The Recurring Run Contract
The Recurring Run Contract is a proposed policy for recurring agent work. It is not a specific scheduling syntax or a required software architecture. It gives a team a common vocabulary for the questions that otherwise appear only during failure handling.
- Contract element: Cadence and time interpretation — What it defines: The intended recurrence, time zone, and version of the scheduling rule — Why it matters: Prevents a vague “daily” instruction from becoming inconsistent across environments or daylight changes
- Contract element: Eligibility window — What it defines: How late a trigger may arrive before the work is skipped, coalesced, or held — Why it matters: Stops stale catch-up work from pretending to be current
- Contract element: Run identity and idempotency posture — What it defines: How one intended run is distinguished from a retry or duplicate attempt — Why it matters: Makes ambiguous delivery and recovery visible rather than silently duplicating work
- Contract element: Overlap and ownership rule — What it defines: Whether a new run waits, skips, observes, or takes over when another run is active — Why it matters: Prevents two instances from racing on the same task state
- Contract element: Input snapshot and freshness test — What it defines: Which sources, task state, and assumptions the run reads, and when they must be revalidated — Why it matters: Keeps a recurring agent from producing a polished answer from old information
- Contract element: Authority, pause, and notification boundary — What it defines: Who may enable, suspend, resume, or escalate the workflow and which changes require review — Why it matters: Separates a timer from permission to make an effect
- Contract element: Disposition and history — What it defines: The final status, evidence posture, handoff, and record retained for later review — Why it matters: Lets the next run distinguish completion, hold, failure, and unknown outcome
The contract can be small. A recurring research digest may need only a few fields; a workflow that creates reviewable artifacts may need more. The value comes from deciding the behavior before the run is late or overlapping.
Make missed windows an intentional choice
If a daily agent misses its expected time, there are at least three reasonable responses:
- Skip: Do not create a late result because timeliness is part of the value.
- Catch up: Run once because the work is still useful after the original window.
- Coalesce: Combine the missed interval with the next eligible interval so the system produces one current result instead of several outdated ones.
No one choice is universally correct. A morning operations check may be worthless late in the day; a periodic maintenance analysis may still matter; a recurring content-research cycle may be more valuable when it refreshes rather than replays old research.
The important point is that the agent should not make this policy up after it wakes. The eligibility window belongs in the contract, and the run history should show whether a missed trigger was skipped, merged, or recovered.
Overlap is an authority question, not just a resource question
Teams often describe overlap as a capacity problem: two runs consume more compute or tools than one. That is true, but incomplete.
Two instances may also read different input snapshots, prepare competing artifacts, send conflicting progress signals, or produce output that each believes is the current version. If a run is still gathering evidence, a new run may be able to observe or assist. If it is preparing an outcome for the same user-facing surface, a new run may need to wait, supersede the older work under a defined rule, or enter a review queue.
The appropriate policy depends on the work:
- Work type: Independent collection or monitoring — Reasonable overlap posture: Allow parallel collection if results are safely deduplicated and labeled by run
- Work type: Single recurring summary or artifact — Reasonable overlap posture: Serialize production so one run owns the current outcome
- Work type: Long-running work with changing inputs — Reasonable overlap posture: Let a newer run assess freshness and either wait, supersede, or request reconciliation
- Work type: Workflow awaiting external confirmation — Reasonable overlap posture: Preserve the hold; do not let a timer reinterpret it as permission to continue
The key is that the system records the reason for the choice. “A previous run existed” is not enough; a reviewer should know whether it was active, complete, held, stale, or of unknown outcome.
Freshness is part of the definition of done
Recurring agents often work with information that can age quickly: documentation, issue state, performance data, public announcements, or project requirements. A run should therefore declare the input snapshot it used and the freshness standard that applies to the result.
This does not mean that every fact must be re-researched every time. It means the run should know which facts are safe to reuse, which need revalidation, and which are time-sensitive enough that a late result should be marked as historical rather than current.
Useful questions include:
- Which inputs define the scope of this run?
- Which claims or dependencies have a freshness limit?
- If the run continues after an interruption, what must it recheck?
- Can an earlier artifact be reused, or does recurrence require a new decision?
- Does the final status describe the age and evidence posture of the result?
If the answer to the last question is no, a successful run may still mislead its reader.
A pause should beat a fabricated completion
Recurring workflows create pressure to produce a regular output even when the conditions are not met. That pressure can lead to stale summaries, duplicated artifacts, or a confident statement that work completed when a tool outcome was ambiguous.
The better behavior is a visible disposition such as:
- completed with current inputs;
- completed with an explicitly bounded limitation;
- skipped because the time window expired;
- held pending a named input, decision, or verification;
- superseded by a newer eligible run; or
- outcome unknown and requiring reconciliation.
These are user-facing statuses, not merely logs. They make a scheduler understandable. A team can see the difference between “nothing happened because the system failed” and “the system chose not to create stale or conflicting work.”
The status should also preserve the next safe step. A hold needs a re-entry condition; an unknown outcome needs an investigation boundary; a skipped run needs a clear next eligible opportunity rather than an invisible retry loop.
Metrics that reveal recurring-work quality
Frequency alone is a poor measure of a recurring agent. A system can run exactly on time and still create little value.
Consider tracking:
- Eligible-run rate: How often did a scheduled trigger become a legitimate run rather than a skipped or coalesced event?
- Fresh-output rate: How often did the result meet its declared input freshness threshold?
- Overlap-resolution rate: How often did the policy resolve concurrent or duplicate work without conflicting outputs?
- Unknown-outcome rate: How often could the system not determine whether a prior run completed?
- Hold-resolution time: How long do recurring tasks wait when they correctly pause for a required decision or verification?
- Useful-outcome rate: How often did the run produce a reviewed, current, appropriately scoped artifact rather than activity for its own sake?
These measures reward the behavior users actually need: timely work when it is useful, and honest non-action when it is not.
A practical adoption path
- Choose one recurring workflow that currently has a simple timer but unclear missed-run or overlap behavior.
- Write the seven contract elements in the language of that workflow.
- Decide which outputs are time-sensitive enough to skip or coalesce when late.
- Give each intended run a durable identity and ensure a retry cannot masquerade as a new cycle.
- Decide whether active work is observed, serialized, superseded, or reconciled when a new run becomes eligible.
- Make the final dispositions visible to the people who rely on the workflow.
- Test late start, duplicate delivery, active predecessor, stale input, pause, and ambiguous outcome cases before expanding the schedule.
The durable insight is straightforward: a recurring agent should not be judged by whether it woke up. It should be judged by whether each run was eligible, current, bounded, and honest about its result.
What we are learning building Virillio Code
Virillio Code is in development. High-level work around durable tasks and recurring execution suggests that a timer is only the beginning of dependable automation. A recurring system needs a clear account of run identity, freshness, overlap, authority, and disposition so it can remain useful without pretending that every scheduled moment deserves the same action. The Recurring Run Contract is a proposed educational framework, not a description of a released scheduler.
Sources and further reading
- Kubernetes CronJob documentation — Recurring jobs need explicit time-zone, missed-schedule, concurrency, suspension, history, and idempotency handling.
- Harness design for long-running application development — Anthropic — Structured task artifacts and explicit state help work continue across many model turns or sessions.
- OpenAI Model Guidance — Long-running agent work benefits from intentional state and constraint handling.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.