Updated

Recurring tasks

A recurring task is something that has to be done every so often (reviewing dependencies, renewing a certificate, checking backups), with its schedule and its history. It works like a cron your AIs understand: any of them asks “what is due?”, takes a task, does it and leaves the result. md-doc does not run anything by itself: it stores what is due, who has taken it and what happened.

What a task contains

  • What to do and how to check it. It is written like a note. It should state the action and a verifiable success criterion, because each run is judged against it.
  • Schedule. It repeats every N days, weeks, months or years, with a next date.
  • Priority: low, medium, high or critical.
  • Its own folders, attachments and references to notes, issues and logs, like the rest of md-doc.

Statuses

Status Meaning
Draft Being prepared: not active, never due, no alerts
Scheduled Active, but not yet time
Due Active and overdue: it can be done now
In progress Someone is doing it, usually an AI

Two ways to count the next date

Mode How it is calculated Example: “review dependencies every month”, planned for the 15th
From done The next one counts from the day it was done If you do it on the 20th, the next is the 20th of next month
Fixed calendar Keeps its calendar however late it was done If you do it on the 20th, the next is still the 15th

With a fixed calendar, short months do not shift the series: a task set for the 31st falls on the 28th or 29th in February and goes back to the 31st in March.

How an AI uses it

  1. It asks what is due. With tasks_list and the “due” state it gets what is overdue. It only takes those, unless you ask for another one.
  2. It takes it with task_start. First thing, before doing anything. It marks the task “in progress” so other AIs do not repeat it. If another one already has it, the call fails and it must not do it.
  3. It does it, following the task content.
  4. It records the result with task_done: success if it was done and checked against the criterion, or warning if there were problems or it could not be fully checked. The comment explains what it reviewed, what it found and what it did.
  5. The next run is scheduled. The task is freed and gets its new date.

If it gives up without doing it, it uses task_release. If the review produces work to do, it creates an issue and links it in the comment.

History

Every run leaves an entry with its result and comment. There is no way to edit or delete an entry, so the history is a reliable record of what was checked and when. An AI can read it with task_runs_list before starting.

Alerts

  • Email on the day it is due, at your notification time and including overdue ones, configurable in Settings.
  • Menu counter with what is due today or overdue.

Sharing

Task folders are shared with your friends just like folders of notes, issues and logs. So each person’s AI sees what is due and which task is already in progress.

Examples

  • Review vulnerabilities in dependencies every month.
  • Check that backups can be restored every week.
  • Renew a certificate every year.

What to use for what

Question Where it goes
How does it work? Note
What happened? Log
What is left to do, once? Issue
What has to be done every so often? Recurring task

Frequently asked questions

Does md-doc run scheduled tasks by itself?

No. md-doc stores what has to be done, when it is due, who has taken it and what the result was. An AI connected through MCP, or you, runs it. It is a cron your AIs understand, not an executor.

How do I make my AIs know which periodic tasks need doing?

Create a recurring task with its schedule. Any AI connected through MCP asks what is due (tasks_list with the "due" state), takes one with task_start, does it and records the result with task_done.

What happens if two AIs try to do the same task at once?

The first one to call task_start marks it "in progress". If another tries to take it, the call fails and it must leave it alone: the first one has it.

Can I see what the AI did each time it ran a task?

Yes. Every run leaves a history entry with its result (success or with warnings) and a comment. There is no way to edit or delete an entry.