Recurring AI Agent Tasks: Proof on Every Scheduled Run

A scheduled job that fails loudly is an incident. A scheduled job that fails quietly is a finding, usually discovered weeks later by someone reconciling a number that never moved. Recurring work is where that second kind of failure lives: the 01:30 export that did not run on the night the clocks went forward, the weekly dependency update that ran twice after a retry, the monthly report that an agent decided was not needed and said nothing about. When the worker is an AI agent rather than a fixed script, the question an operations manager has to answer gets harder, because an agent run can finish, look plausible and still not have done the job.

The wider gap is well documented. McKinsey's State of AI survey (November 2025) found 88% of organisations using AI in at least one business function, while only about 6% capture material EBIT impact. In our view, recurring operational work is one of the places that difference is won or lost, because it is boring, frequent and easy to stop checking.

This guide is written for the operations manager or head of delivery who owns a set of recurring tasks and is considering handing some of them to agents. It covers how scheduled runs fail, what the scheduling literature says about skipping versus repeating a run, how daylight saving breaks a fixed-time job, and what each run should prove before it counts as done. It does not repeat the general case for proof before done, which lives in our AI agent work management guide, and it leaves vendor-by-vendor tracker comparisons to the posts on Linear and AI agents and ClickUp and AI agents.

This guide is shipped by the team behind Cognibl, work management for teams where people and AI agents share one board and a task reaches done only once its proof is attached. Or see DATS, our five-stage system for placing AI where it pays.

What is a recurring AI agent task?

A recurring AI agent task is a piece of work, written once, that an AI agent performs again on a fixed schedule, such as a daily reconciliation or a weekly dependency update. In Cognibl, from DILR.AI, the written task is a template that nobody works on directly. Each scheduled run copies it into a new task, assigns the schedule's agent and starts, so every run carries its own status and its own evidence.

That template-and-copy design is the difference between a recurring task and a repeating reminder. In many classic trackers, in our experience, a recurring item means the same card reopening, so last week's comments, last week's status and this week's work blur together. In Cognibl, the recurring tasks page on cognibl.com describes each run as "a new task for a cloud agent, with its own proof", and the copy has "its own proof, comments and status". The template holds the definition of done; the run holds the evidence that this particular run met it.

The cadences are deliberately plain: hourly at a chosen minute, daily, weekly on a chosen day, monthly, or once, each in its own time zone. Monthly schedules run only on the 1st to the 28th, which the page explains as the way to make sure no month is skipped. There is no cron expression field. Cognibl's own answer is that a short list lets anyone on the team read a schedule and know when it runs, and that a pattern the list cannot express usually needs two schedules. Every schedule reads back as a sentence, in the form "Every Monday at 09:00 Europe/London".

Two design choices are worth naming because they shape what follows. First, recurring work in Cognibl is always done by a cloud agent, and the page says "the database enforces it": a task owned by a person is handed to the chosen agent when it is scheduled, and the dialog says so before saving. Second, every copy goes through the same proof check as any other task, which is the subject of most of this guide. The cognibl.com site lists recurring tasks next to cloud agents and version control, and DILR.AI's own Cognibl page summarises the feature as recurring tasks on a schedule where "every run is a new task with its own proof". For the full product picture, our plain-English explainer on Cognibl covers the board, the library and the gateway.

How do scheduled agent runs fail without anyone noticing?

Scheduled agent runs fail quietly in four main ways: a slot is missed and nothing records it, a slot runs twice after a retry, a long run overlaps the next one, or a run finds nothing to do and ends without saying so. Each failure leaves no error behind, so the team running recurring AI agent tasks only finds it when a downstream number stops reconciling.

Most of these failure modes were not invented by AI. Missed and doubled runs are properties of scheduling itself, and widely used schedulers document them openly. The Kubernetes documentation for CronJobs says a CronJob creates a Job "approximately once per execution time of its schedule", and that "there are certain circumstances where two Jobs might be created, or no Job might be created". Kubernetes tries to avoid both, but does not completely prevent them, which is why the same page tells you the Jobs you define should be idempotent. It also notes that the controller checks every 10 seconds, and that when it counts more than 100 missed schedules since the last run, it does not start the Job and logs an error instead.

Hosted schedulers carry their own versions of the same risk. The GitHub Actions documentation says the schedule event "can be delayed during periods of high loads", that high load times include the start of every hour, and that under sufficiently high load "some queued jobs may be dropped". In a public repository, scheduled workflows are disabled automatically when no repository activity has occurred in 60 days. Amazon describes EventBridge Scheduler as providing at-least-once delivery, which is a reliability guarantee that, by definition, permits a second delivery. For teams weighing tracker-native agents, our post on Jira and Rovo agents looks at how the record of agent work differs between tools.

An agent adds a fifth, subtler failure on top of the four. A script either runs or errors; an agent can run, produce output and still not have done the work, for example by reporting a reconciliation as complete without having opened one of the payout files. That is the general problem our guide to verifying AI agent task completion addresses, and it matters more on a schedule, because nobody is watching the 09:00 run as it happens. The practical consequence for an operations manager is simple: on a recurring task, the absence of an alert proves nothing. What you need is a record in which every expected slot has an outcome, including the slots that were skipped, could not start or found nothing to do.

Should a scheduler skip a run or risk running it twice?

A scheduler that cannot guarantee exactly-once execution has to choose which mistake it prefers: skipping a run, or running it twice. For recurring AI agent tasks that touch money, customers or code, skipping and recording the skip is usually the safer default, because a missed run can be replayed deliberately while a duplicate run may already have acted on the world.

The clearest statement of that trade-off comes from Google's site reliability engineering team, in the chapter of the Site Reliability Engineering book on distributed periodic scheduling. Its author describes a scheduler that serves most of Google's internal teams, and sets out the rule it follows:

"In general, we favor skipping launches rather than risking double launches, as much as the infrastructure allows. This is because recovering from a skipped launch is more tenable than recovering from a double launch."

The same chapter explains why there is no single answer. Some jobs, such as garbage collection, are idempotent and safe to launch more than once; others, such as an email newsletter or a payroll run, are not. A garbage collection job every five minutes may be able to skip one launch, but a monthly payroll job should not be skipped. The owner of each job has to know which kind it is, and the scheduler has to make the failure visible either way. Writing that distinction down for each task is what a definition of done is for, as our agent task verification guide sets out.

Kubernetes exposes the same choice as configuration. Its concurrencyPolicy field can Allow concurrent runs (the default), Forbid them, or Replace the running Job with the new one, and its startingDeadlineSeconds field tells the controller to skip an instance that is too late to be useful. The documentation's own example is a backup that is worth taking up to eight hours late but not later. These are good controls for a platform team running deterministic scripts. They are less natural for an operations manager handing a reconciliation to an agent, who should not need to know what a concurrency policy is to get a safe default. Keeping guardrails, observability and rollback live once a system is in production is the job of an AI execution office, not of a scheduler setting.

Cognibl takes the skip-and-say-so side of the trade-off and states it in plain terms. Its recurring tasks page says "a retry cannot run a slot twice", and that "a run still going skips the next one, and says so": the new firing is "skipped and recorded as skipped, rather than starting a second run on top of the first". A firing that could not start at all, for example because the agent has been archived, is recorded too, "so the history never has silent gaps". Pausing a schedule is a single action, and resuming "starts from now, with no flood of catch-up runs", which avoids a backlog of catch-up runs; Kubernetes handles a similar situation differently, refusing to start a CronJob that has missed more than 100 schedules.

The same diagnostic logic underpins our AI operating model work, where each recurring AI process gets a named owner, a review cadence and a turn-off protocol before it goes live.

How do daylight saving changes break a daily 09:00 agent run?

Daylight saving changes break a fixed-time job because one local hour disappears in spring and one repeats in autumn. A daily 09:00 run is safe, but anything scheduled in the early hours can be skipped or doubled. In the UK the clocks went forward on 29 March 2026 and back on 25 October 2026, so a recurring AI agent task in that window needs a defined rule for both nights.

According to GOV.UK, UK clocks go forward one hour at 1am on the last Sunday in March and back one hour at 2am on the last Sunday in October; in 2027 the dates are 28 March and 31 October. Every scheduler has to decide what happens to a job set for 01:30 on those two nights, and they do not all decide the same way.

The classic Unix answer is in the cron(8) manual page: local time changes of less than three hours, such as daylight saving changes, are handled specially for jobs that run at a specific time. If the clock jumps forward, jobs that would have run in the skipped interval run immediately; if it moves back, "running the same job twice is avoided". Jobs that run more often than hourly are scheduled normally, which is a detail that catches people out. GitHub Actions runs schedules in UTC unless you set an IANA time zone, and when you do, a job in a skipped spring-forward hour advances to the next valid time. Kubernetes made CronJob time zones stable in v1.27; without one, the schedule follows the controller's local time zone, which may not be the one your finance team works in.

Cognibl's rule is written for the person who owns the work rather than the person who runs the cluster. Each schedule keeps its own time zone, and the next run is worked out in local wall-clock time, so "09:00 stays 09:00 through daylight saving". When the clocks go back, the repeated hour fires once; when they go forward, a time inside the missing hour fires just after the gap instead of skipping the day. For a UK team, the practical checks are short: set every recurring task in Europe/London, not UTC, if the work follows the business day; avoid scheduling consequential runs between 01:00 and 02:00; and look at the run history for the last Sunday in March and October, every year, to confirm one run per slot. If you want those rules set once across a team, book a scoping call with us.

What should each scheduled run prove before it counts as done?

Each scheduled run should prove that it met the template's definition of done for that specific run: what was checked, what changed, and where the evidence sits. In Cognibl, every run of a recurring task is an ordinary task with the same proof check, so it cannot reach a done status without proof attached, and a run that found nothing to do can end that way as a valid, recorded outcome.

The proof itself is the same object Cognibl uses everywhere. On DILR.AI's Cognibl page, proof is described as a CSV, the documents it references and, for code, a coverage report, and "without it the status change is refused, for people and agents alike". The page also notes that its proof of work "has nothing to do with cryptocurrency mining", a necessary clarification, because the phrase means something else to most search engines. For a recurring task, the definition of done lives on the template and every run is judged against it, so the standard cannot drift from Tuesday to Wednesday because a different agent run interpreted it differently.

The "nothing to do" ending deserves more attention than it usually gets. A reconciliation on a day with no payouts, or a dependency check with no updates available, is a legitimate result. If the only acceptable ending is a completed artefact, agents learn to produce something; if a silent finish is acceptable, the history fills with runs nobody can explain. Recording "nothing to do" as its own outcome, with the reason, makes the empty run auditable rather than invisible, the same refusal logic our Cognibl explainer describes for ordinary tasks. The cognibl.com example shows exactly this: one run of a Stripe payout reconciliation marked "Nothing to do" with the note "no payouts that day".

For an operations manager writing the template, three questions produce a usable definition of done. What would a person check to know this run worked, such as matched totals or a closed list of exceptions? What artefact proves it, such as a reconciliation CSV, a report file or a pull request? What does "nothing to do" look like, and what evidence shows the agent actually looked? The third question is the one most teams skip, and it is the one that separates an empty run from an unexamined one. The broader method behind those three questions is set out in our guide to proof of done for agent work.

How do you audit a year of recurring agent runs?

Auditing a year of recurring agent runs means checking that every expected slot has exactly one recorded outcome, and that every done outcome carries proof. The useful test is completeness, not volume: count the slots the schedule should have fired, count the outcomes in the history, and treat any difference as a finding before trusting a single result from the recurring AI agent task.

Cognibl's history view is built around that test. The recurring tasks page shows every run with its outcome, tokens and time, plus a year-long grid, so a missing day stands out visually rather than hiding in a list. Because skipped firings are recorded as skipped and runs that could not start are logged with their reason, an unexplained gap in the history is a finding to investigate, not a quiet day to assume. Behind the history, Cognibl writes every agent tool call, allowed, refused or failed, to a trace that is append-only, hash-chained and redacted at capture, written by the gateway rather than reported by the agent. Redaction at capture is a limit worth stating: the trace supports reconstructing what an agent did, but it will not hold every value the agent saw.

The audit itself can be a short monthly routine, owned by whoever owns the recurring work:

1. Completeness. For each schedule, compare expected slots with recorded outcomes. Any mismatch is investigated first.
2. Outcome mix. Look at the share of done, nothing to do, skipped and could not start. In Cognibl a skip is recorded when a run is still going at the next firing, so a rising skip rate suggests runs are getting longer than the interval.
3. Proof sampling. Open a handful of done runs and read the proof against the template's definition of done, as a reviewer would.
4. Clock-change nights. In late March and late October, check the runs either side of the change.
5. Reopens. Note any run whose result was later found wrong. That is the signal the definition of done needs tightening.

Cognibl's project metrics support the reopen check. Its five delivery metrics include first-pass verification rate by flow type and reopen rate within 30 days, alongside median cycle time, human wait share and verified throughput per week. Its AI flows for proof validation and project status summarise and flag, but never decide, so the judgement in step three stays with a person. If the recurring work is part of a regulated process, the evidence questions are the same ones we cover for agent work in accounting practices, and the controls around it, such as guardrails, observability and rollback, belong to an embedded AI execution office rather than a tool setting.

Which recurring work should you hand to an agent first?

Hand an agent recurring work first where a missed run is recoverable, a duplicate run is harmless or blocked, the result can be checked against a clear artefact, and "nothing to do" is a normal outcome. Reconciliations that only read and report, scheduled reports and dependency update pull requests fit that profile well; recurring tasks that send money or messages to customers should come later, if at all.

Cognibl's own page names reports, reconciliations and dependency updates as the weekly chores to hand to an agent, and in our view that list matches the reliability logic above. A reconciliation that reads two sources and writes a list of exceptions changes nothing if it runs late, and its output is easy to check. A dependency update lands as a branch and pull request, and in Cognibl agents stop at a pull request because only people merge, so a duplicated or wrong change stops at review. A status report is idempotent in practice: a second copy is noise, not damage. The SRE chapter's contrast between garbage collection and payroll is a useful lens here, and it can be turned into four questions for each candidate task:

There is a second reason to start with read-and-report work. On DILR.AI's Cognibl page, tool access is read-only by default and anything the policy map does not allow is blocked and logged, and each cloud agent runs in its own microVM, which our post on cloud agent isolation explains. Read-and-report recurring work fits inside those boundaries without asking for wider access. For engineering teams in particular, scheduled dependency and maintenance work is a natural first candidate, and the trade-offs of AI-assisted delivery are covered on our AI developer productivity page.

If you are not yet sure which processes deserve an agent at all, that is a placement question before it is a tooling one, and an AI placement diagnostic is designed to answer it across the business rather than one schedule at a time.

What is the best way to run recurring AI agent tasks in 2026?

The best way to run recurring AI agent tasks in 2026 depends on what the task is. For deterministic scripts with no judgement involved, an infrastructure scheduler such as Kubernetes CronJobs or GitHub Actions is often the better fit. For agent work whose result has to be proved on every run, a work-management layer that records each run as its own task with evidence is the stronger choice.

Our criteria, which are a view rather than a measurement, are five: every slot has exactly one recorded outcome; a retry cannot create a second run; the schedule follows the business's own clock through daylight saving; a done status requires evidence judged against a written definition of done; and the owner of the work can read the schedule and the history without platform help. Against those criteria, the options sort fairly clearly.

Kubernetes CronJobs win where a platform team already runs the cluster and the job is a container that either succeeds or fails. They give finer control than Cognibl does, including concurrency policies and starting deadlines, and they accept full cron expressions, which Cognibl deliberately does not. GitHub Actions schedules win for repository chores where a five-minute minimum interval and possible delays at the top of the hour are acceptable. AWS EventBridge Scheduler suits scheduling calls to AWS services from a managed service, with at-least-once delivery that your targets should be built to tolerate. Notion's Custom Agents, which Notion says "automate recurring work for your entire team" and include status update agents that write recurring reports, suit teams whose recurring work lives inside a Notion workspace.

Cognibl, built and run by Dilr.ai Ltd in London, fits where the recurring work is done by an agent and someone will later need to show that each run happened, once, and met its standard. Its trade-offs are real: recurring work is agent-only, so a person cannot own a recurring task there; the cadence list is short by design; and the agents are Claude Code and Codex agents, so it suits work a coding agent can do with the code, files and read-only connections you enable, not every kind of recurring task. If your team uses a framework such as LangGraph to build the agent itself, the work-management layer sits above it, as our LangGraph work-management post explains, and the two are not alternatives.

Can a person be assigned to a recurring task in Cognibl?

No. In Cognibl, from DILR.AI, recurring work is always done by a cloud agent, and its recurring tasks page says the database enforces that rule. If a task belongs to a person when it is scheduled, saving the schedule hands it to the chosen agent, and the dialog says so before the change is saved, so ownership never changes silently.

The reasoning follows from the proof model. A person can still write the template and review the proof on any run, and the same done rule applies to people and agents on ordinary tasks. What changes on a schedule is only who performs each run. Teams that want a person to do recurring work can keep using a calendar reminder or their existing tracker, and should talk to us if the boundary is unclear for their process.

Does pausing a Cognibl schedule trigger catch-up runs?

No. Pausing a schedule in Cognibl stops future firings, and resuming starts from the current time, with no flood of catch-up runs for the slots that passed while it was paused. Cognibl's recurring tasks page describes pause as a single action, so for an audit the paused period is best treated as having no expected slots, which keeps the run history honest.

That choice matches the skip-rather-than-double principle. If the paused period contained work that genuinely has to be done, such as a month-end reconciliation, the right move is to run it once, deliberately, as an ordinary task with its own proof, rather than letting a scheduler replay every missed slot at once. Deciding which recurring processes carry that kind of obligation is governance work that our DATS consulting covers, and our comparison of an AI operating model with a centre of excellence covers who should own those decisions.

Want to see this in production? Try Cognibl on cognibl.com, read how our strategy writing treats agent work, see our DATS methodology, or read about our approach to placing AI inside enterprise systems.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.