How to schedule recurring AI tasks
The useful AI work in an office is rarely a one-off question. It is the same check every Monday, the same summary at month end, the same review whenever a new export lands.
Short answer
Write the task as a fixed instruction, choose a trigger — a schedule, a watched folder or a webhook — and run it with a tool that records every run: the instruction, the model, the answer and the cost. Start with tasks that report rather than act, check the first week of runs by hand, and keep a way to stop everything at once.
Which trigger fits the job?
| Trigger | Fires when | Example |
|---|---|---|
| Schedule (cron) | At set times | Every weekday at 07:30, produce the day's follow-up list from the notes in the instruction |
| File watch | A watched file or folder changes | When the month-end export is replaced, run the month-end review |
| Webhook | Another program sends an HTTP request | A script posts this week's hours; the task works out the overage and explains it |
Cron schedules in two minutes
A cron schedule is five fields: minute, hour, day of month, month and day of week. An asterisk means "every".
| Schedule | Runs |
|---|---|
30 7 * * 1-5 | 07:30, Monday to Friday |
0 9 1 * * | 09:00 on the first day of every month |
0 17 * * 5 | 17:00 every Friday |
0 */2 * * * | On the hour, every two hours |
Times are the computer's local time. A scheduler on a laptop only runs while the laptop is awake: a job due while the lid was closed is missed. Put important schedules on a machine that stays on.
Write instructions that survive running unattended
- Be specific about the input. Say exactly what the task works from, not "the latest figures".
- Say what done looks like — the format, the length, the headings.
- Tell it what to do when something is missing: say so and stop, never guess.
- Keep arithmetic out of the model. Let a calculation engine produce the figures and the model explain them. See how to stop AI getting numbers wrong.
- Report first, act later. A task that writes a summary for a person is safe to schedule; one that sends, files or deletes is not, until you have watched it for a while.
Setting it up in OpenClerq
Open Triggers in the desktop app and add a schedule, a watched path or a webhook, each with the instruction it should run. Triggers are stored in OpenClerq's local database, and a schedule that is not valid cron is rejected when you save it, with the reason. The same configuration can be sent to the gateway directly:
POST /triggers
{
"cron": [
{ "id": "monday-review", "schedule": "0 8 * * 1",
"message": "List the recurring month-end checks and who owns each." }
],
"file": [
{ "id": "month-end-export", "path": "/Users/you/Exports/month-end.csv",
"message": "The month-end export has changed. Run the month-end review." }
],
"webhooks": {
"weekly-hours": { "message": "Weekly hours received." }
}
}A script on the same machine fires the webhook with the gateway token, and can send the data with it — the message in the body replaces the stored one:
curl -X POST http://127.0.0.1:18790/webhook/weekly-hours \
-H "Authorization: Bearer $(cat ~/.clerq/gateway-token)" \
-H "Content-Type: application/json" \
-d '{"message": "calculate (logged - included) * rate where logged=46.5 included=40 rate=95"}'Every firing runs the instruction through the same pipeline as the Ask panel — the calculation engine first when the instruction contains a calculation, then the model — and is recorded as a run with a step trace, the model used, tokens and cost. A webhook call returns the run id so the script can look the run up.
To stop things: cancel a single run from the run list, or use the kill switch, which refuses pending approvals, cancels everything running and pauses all triggers until you resume them.
Limits today
In release 0.5 a trigger runs a fixed instruction. The model does not yet open files or call other systems on its own, and a schedule missed while the computer slept is not caught up. Release 0.6 adds a tool-calling loop under a policy engine, catch-up for missed schedules, and budgets that pause an automation instead of letting it spend. See the roadmap.
Rules for AI that runs on its own
- Every automation has an owner who reads its runs.
- Every automation has a limit — on time, on spend, or both.
- Nothing arms itself. A new automation runs manually until someone has checked its output.
- A person approves anything irreversible: sending, filing, paying, deleting.
- There is one switch that stops everything, and everyone knows where it is.
Frequently asked questions
Can I schedule prompts in a chatbot instead?
Some assistants offer scheduled prompts. They run in the provider's cloud, on its terms, and the record of each run lives in the provider's account. A local scheduler keeps the instruction, the data and the log on your own machine.
What happens if my computer is asleep when a task is due?
In OpenClerq 0.5 that run is missed. Release 0.6 adds catch-up: a schedule missed while the machine slept runs once when it wakes. Until then, put important schedules on a computer that stays on.
How do I stop an automation that is misbehaving?
Cancel its run, or use the kill switch, which cancels every running run, refuses pending approvals and pauses all triggers in one step. Triggers stay paused until you resume them; you can still run tasks by hand.
How much does a scheduled AI task cost?
It depends on the model and on how much text goes in and out. OpenClerq records the tokens and cost of every model call against its run, so you can see the cost of each automation rather than one monthly total. A local model has no per-token cost. See how to track AI costs per task.